Perms Are Not for Hair- Understanding User Access

Once upon a time, user permissions ("perms") were controlled by user profiles. Then in 2023, Salesforce announced, via a blog post from Cheryl Feldman, the "end of life" (EOL) of permissions on profiles. Eventually profiles will be stripped nearly bald and all permissions will be assigned by permission sets. All that will be left on profiles will be those settings or permissions that are 1:1 with a user, like the default app, default record type, page layout assignment, login hours, and a handful of other things. Everything else, including settings like Edit Reports, or object and field access will be assigned as part of a permission set (or "permset").

It's a couple years later and I'm not sure we're really any closer to that future from a technical standpoint. That blog post has been updated a few times to indicate that the EOL for permissions on profiles is not on the horizon. But it's been clear for a while that the future of user permissions is going to be one of very basic profiles and a lot of permission sets. So it's time for admins to start thinking more about their perms.

It's time to start thinking about how you will eventually move your organization into the permission set-forward future.

Apparently this is about to be a short series of blog posts. Today we start with the basics of understanding user access.

Permissions as a Layer Cake

To switch visual puns and metaphors, I like to think of permissions as a layer cake. The future of user management is all about layering on the right access for each user.

User License

We start with a base that everyone needs, which is the user license. (Without a license available, you're not going to be creating a new user. Whether platform users, community users, API-only integration users, or full Salesforce licenses, everyone that logs into Salesforce is doing so based on a user license.)

For today's discussion, we don't need to put too much time into license type. But it's definitely there, like the bottom crust.

Profile

As I mentioned above, the profile is 1:1 with a user—you can't have a user without them having a profile. That makes profile the second layer of our cake. (To be honest, I usually think of profile as the first layer.)

In most orgs today, Profile is the true heart of your user setup. You probably have a profile that corresponds to each of your departments. You may have more granularity than that, with regular users and power users within each department. But that's often all there is.

And once you've assigned a profile, that might be it. The profile contains all the app permissions, object CRUD (create/read/update/delete), and field level security the user needs to do their job, so they don't routinely get any permission sets.

If this is your org at the moment, don't feel bad. This was "the way" for a long time. As long as you have a couple of profiles, rather than everyone being a sysadmin, you're ahead of a lot of orgs. (Please do not do that!)

If your org's user access is just license and profile, that's just two layers. I guess you have a user access pie.

Pie is delicious, so I can't fault you.

It's Salesforce's/Cheryl's plan that eventually there won't be a whole lot of substance to the profile. It can't go away—you need something to hold those 1:1 settings. It's just going to grant a whole lot fewer powers than it does today. So eventually, just having profiles is not going to be enough.

Permission Sets

In the layer cake future, all the power is going to come from permission sets, piled onto your base profile. Each layer has its own flavor and texture—which, in our metaphor, means that they each grant different permissions and they build on each other.

When I'm planning permissions, I usually start with a "baseline" permission set that I'm planning to assign to every user. This permset is going to grant access to the shared common set of objects and fields that everyone needs to access. This means Account and Contact, for sure, plus any custom objects that are at the heart of your org's Salesforce usage. Depending on the org, not all users may need to see Opportunities. But I definitely put some of the NPSP objects in my baseline permission set as well, such as Relationships. And I put baseline system permissions in here as well, such as Run Reports, Schedule Dashboards, or Chatter Internal User.

Let me be clear: this is not the only way to do this. I tend to work with smaller clients and we are prioritizing simplicity. Your needs may vary. Or you may have fewer settings and objects truly in common for all your users. There's no requirement for a single baseline permission set. I just find it simpler to work with. (And I do not want to use permission set groups, for reasons I'll explain below.) In some small/simple orgs I manage to have basically only this one baseline permset.

I Don't Love Permission Set Groups

I would be remiss if I didn't mention permission set groups ("PSGs", or "permsetgroups") in this discussion. But I'm only going to touch on them briefly because I don't like them and I mostly don't use them. As their name implies, permission set groups are a way to bundle a bunch of permission sets together. Then you only need to assign the PSG and the user gets the access of all the permsets inside.

Permsetgroups have one nifty feature: muting permission sets. Within a permsetgroup you can create a muting permission set that turns off permissions that reside in the underlying permsets. Note that a muting permission set only applies within the permsetgroup. So if a permission set outside the group or a second permission set group grants a permission that's muted in the first one, the muting doesn't apply. To me, it's not that much less work to use muting than to make permsets with fewer permissions and then give a Super User permset to add power. And it's less confusing.

The other downside that keeps me away from permission set groups is that they have to recalculate any time there is a change to one of the permission sets within them. Every so often I need to open the permissions for a few objects in tabs and make changes to each. But if those object permissions are within a permission set group, each save has to finish calculating before I can hit Save on the next. It usually takes a full minute between saves. That's very annoying. But even more frustrating is that a permission set group can fail its recalculation silently! If you happen to be on the PSG list view, there is a Status field

but it's not that likely that you're going to sit there waiting to see that it shows Updated. And you don't get any email notification that your permission set change led to a failure in the permission set group recalculation.

Last: it's just not that much harder to assign several permission sets than it is to assign a group. And by using only permission sets you only have one place on the user that you need to investigate when you're trying to figure out their user access picture. And there are ways to make assigning the right permission sets easy, so I think groups aren't that neccessary.