How I Do Perms

Third in a series.

In part one I used a layer cake metaphor to explain licenses, profiles, and permission sets.

Part two used Personas as the recipe for which users get which access and User Access Policies as the tools to execute the recipe.

Now we talk actually getting it done!

Disclaimer here: I have not invented anything new. At best I've synthesized smart ideas from others and translated them into the context of organizations the size and capacity of my small nonprofit clients. Hat tip in particular to Mike Reynolds who has been presenting on his persona-based framework for user access for years. And to many others from whom I've learned tips and tricks.

Step 1: Define Profiles

Remember: the profile is the bottom layer of your cake. We're working to get to a world where profile is used to set essentially one thing: defaults. Since a user can have just one profile, this is the place you are going to set things that can't be multiple, meaning default record types and, if you're using them, page layouts. The former are clearly required: for objects with record types, you need to set which willl be applied if none is selected or which will be offered as the default on the New Record screen. With Dynamic Forms you may have less need for Classic page layouts that get assigned by profile, but they still have their place. (I'm still using them in most cases.) Page layout assignment has to be at the profile level (1:1 with user) because it doesn't make sense that someone could see multiple page layouts.

I am not working in environments where we have login IP ranges or those kinds of security settings that may also have to be applied at the profile level.

Sidebar: I learned from one client that in Pardot (or Marketing Cloud Account Engagement, or whatever they're calling it these days...) you can only control some access based on the Salesforce user profile. So they have multiple profiles within a single team of Salesforce users. (Examples: Sales Team and Sales Team Tier II) These profiles differ only in name. Each profile is minimum access and they have the same page layouts and defaults. But they have to exist to make things work on the Pardot side.

Step 2: Build Permission Sets

It feels almost redundant to mention it after two prior blog posts, but the first thing I have to get in order is my pile of permission sets.

[Based on today's title I'm using the metaphor of how I do perms, so maybe that means "getting my scissors, chemicals, and tools ready next to the stylist chair." But I think the better metaphor here is that I bake my several thin cakes of complementary flavors and set them onto cooling racks.]

In theory, for a simple org I could get away with having just a single "baseline" permission set. But in practice, particularly as I look toward getting all users onto minimum access profiles, I will need at least two that everyone is going to get:

1. Baseline Permissions - This grants access to the objects and fields that everyone uses. Also includes the kinds of system permissions that everyone needs (Run Reports, Send Email through External Email Service, etc.). This permission set is not tied to a license type. See more below, but this permission set should generally only grant "CRU" permissions (Create, Read, Update).

2. Standard Object Tabs - I actually put it right into the description of the permset why it exists: "Because the baseline permset is not limited to a license type it can't grant access to the standard object tabs. So this permset is used to do that." This permission set is set to License = Salesforce. All it does is set the tab to Visible for Account, Campaign, Contact, Case, Lead, Opportunity, Task, etc.)

   1. If I'm going to have integration users, they'll need a version of this permission set where License = Salesforce API Integration.

   2. If I'm going to have platform users, they'll need a version of this permission set where License = Salesforce Platform.

In order to adhere to the principle of least priviledge, my baseline permission only gives the lowest common level of access my users need. That might mean it only gives View access to all objects, if I have a user that only should ever run reports. In the kinds of organizations I work with, everyone needs at least Create and Edit on most objects. But they don't need Delete! So when I'm being diligent, I keep Delete out of the baseline permission set. Then I have a Delete permission set for those few users that need it. (But I'll be honest and transparent: Sometimes the baseline permission set includes delete. I don't let the perfect be the enemy of the good. We are all on a journey toward perfect security.)

Here's the start of the permission sets list view for one client:

Of course, I start having more permission sets for other discrete areas of permission that only some people will need. This means things like access to a particular sensitive data field (Social Security Number) or a distinct piece of functionality that has its own objects and fields. The more complicated the org, the more permission sets there are going to be. If you get very large and complicated you might think permission set groups will help organize things. But I only work with small and medium organizations so I find permission set groups create more problems than they solve, as I noted in the first post of the series.

One last quick note regarding permission set naming: You probably noticed in my list, above, that the permission sets for that org all start with "1DCPC." The org's initials, of course, are "DCPC" and that's the main thing that I try to do: start all my permission sets with the org's initials. That way they all sort together in alphabetical lists and it's easy to remember where in the alphabet to look. In this case I went one step further and added "1" so that they would all group at the very top of the list. That's even more convenient and I wish I'd done it all the time in all my client orgs!

Step 3: Make A Persona Field

As I said in the last post, personas are not an actual feature of Salesforce. I make my own Persona field. This is nothing more than a custom picklist field on the User object.

I put that new field on the User page layout and make it required.

[Yes, it annoys me that the User page layout isn't very customizable. I can only put the Persona field down "below the fold," so I often haven't filled it when I try to hit Save and then I'm prevented until I do so. Maybe—hopefully—someday Salseforce will give us the ability to really control user page layouts.]

I create a picklist value for each persona for each license type. If you've been tracking carefully throughout this series (and before), you've got it in the back of your mind that users on different license types will need permissions assigned slightly differently, even if they end up with the same permissions in the end. So if you're in an environment with just one license type, then things are going to be simpler for you. But if you've got a mix of full users and platform users—as many of my clients do at this point—you have to account for the difference at the crust layer of the cake.

I think it's pretty easy to choose among persona/license combos even though that makes for a longer list. The other option is to have just a persona, but then you'll have to distinguish, when assigning permissions, whether you're on license type A with that persona or license type B. I find that less convenient to actually accomplish. (More below.)

If you're using this post to start retrofitting your org to do permissions this way, don't forget that once you create this field and set it as required on the page layout that only takes care of future new users. You also need to backfill this field for all current users.

Sidebar: It would be an option to make yourself multiple profiles, one for each persona. If these were each minimum access profiles that are distinguished only by their name they essentially serve as your persona. But I don't love this option for two reasons:

1. Your org is going to have all sorts of extraneous profiles you can't get rid of, making it all too easy to choose a wrong profile.

2. By combining profile and persona you lose any potential ability to distinguish. (Giving some users the same persona but different page layouts for example.)

Step 4: Create User Access Policies

Now I create one user access policy to go with each of the Persona picklist values.

The persona is used as the criteria for applying this user access policy (along with the user being Active, of course).

If a user meets that criteria, they'll get the baseline permission set, the standard objects permission set, and any other permission sets that are needed for a user of that persona to do their work. (Since the user access policy can assign multiple permission sets, this is why I don't see a need for permission set groups.) And they'll be added to one or more public groups, which can be used to control things like report folder sharing.

Last, but definitely not least, we are going to enable this user access policy and set it to run every time a user is created or edited.

That will ensure that if you change a user's persona, they'll get the new permissions you expect to go with it. You can also click to apply the policy to existing users that meet the criteria.

Now test your UAPs by creating and updating some users.

UAP Gotchas:

When you're setting up UAPs, you give them an order in which they will be evaluated. Once Salesforce finds one UAP whose criteria applies to a user, it stops evaluating the rest. This means you can't use them to incrementally build up permissions based on several different criteria that a user might meet. This is why I go with the persona field: it allows me to guarantee that the right UAP will apply.

For this same reason, I don't really use the Order field on the UAP. It's supposed to allow me to control that one UAP will be found before another. But I'm already controlling for that with the profile field. As you might have noticed in the screenshot above, I just set them all to 1. I could just as easily set them to be sequential. With my persona field based rubric, it makes no difference.

In a larger and more complicated org than I work with, I imagine User Access Policies is not a sophisticated enough feature to get everything done. In that case, I think Flow is probably the next best option.

Step 5: Getting from Here to There

The final element is to actually get to the setup I've just described from wherever the org has started off. (Hat tip Katie Villanueva for asking about this on MVP Office Hours.) This framework is easy to implement if I'm starting from scratch. But I rarely get to start from scratch. I mostly inherit orgs with years of technical debt, little or no documentation, and sometimes everyone is a sysadmin. It can be a long process to give an org a stylish perm.

That process might deserve a whole post of its own, but I'm not even sure I could give comprehensive guidance. Ultimately it's a lot of manual work that is very org-specific. Let me give at least an outline:

• I go through objects and reduce page layouts as much as I can. I figure out what is common and uncommon about page layouts assigned to one profile or another. In my experience, it's rarely worth having so many page layouts, they usually differ in only minor ways. It's frequently those different page layouts that actually are the reason for having multiple profiles. So as I consolidate page layouts, I find that that I can also be consolidating profiles.

• While I'm at it, I reduce record types, deactivating as many as possible.

• I absolultely get rid of Lightning Record Page assignments by app and profile. They're way too much to try to manage or compare. Conditional display can usually handle the kinds of things people might have made different by app or by profile and then, at least, I'm only working on the display in a single builder.

• I compare profiles to find how they differ regarding object and field access, default record types, things like that. In a small org, I can probably reduce down to just one or two.

• I try to look for any conditional visibility rules on Lightning record pages that might be based on profile.

• I learned recently, that if you use Dynamic Forms and have placed an individual field with conditional visibility it does not show up as a Where is this used? entry for the field. So just know that dynamic forms are going to be a complication in this migration.

• All of this requires coordination with the users in the organization. Even if I've determined that page layouts all have the same fields on them, consolidating down to one probably means changing the order of at least a few fields for a few people, even if only in minor ways. They are entitled to some warning, at the very least.

Once I've worked through all that I hopefully have a much smaller list of profiles than I started with. Sometimes I'm down to just one. Maybe three at the max.

Then I make minimum access versions of each profile. For clarity, I give them the same name as the original profile, with "minimal" added. It will be clear to me later that those on "Program User" are going to move to "Program User - minimal." I can't decide whether it saves me time to clone the original and strip it down to minimum access or to start with a fresh profile (no access) and build it up to the minimum access that it needs. But either way, I should end up with a new profile that has

• default page layouts and record types that match the profile it came from,

• no object nor field access,

• and few, if any, app or system permissions.

My general method for doing this is to open the original profile in a window to the left and the new one in a window to the right and click through each section comparing them side-by-side. This is tedious work. I don't think there's much way around that.

With my minimum access profiles, my personas, my permission sets, and my user access policies ready, the last step is to test under real world conditions. That means that I'm going to have to find someone of each persona to be my first...victim. This needs to be someone that I have a relationship with, because I might make their job difficult for a day or two. I warn them that I'm going to switch them over and ask them to look for things that look different, stop working, or otherwise might be related to the change. I give them a direct line so we can fix things quickly. There are usually a few hiccups in the first day or two.

After switching someone, I like to let them go for a few weeks before I'm ready to move everyone else of the same persona. This is a slow-and-steady process, but I get there eventually.