Baking Your User Access Layer Cake

In part one of [what has become] a series, I used a layer cake metaphor to explain licenses, profiles, and permission sets. If I'm going to really embrace that metaphor (And I am!), then it's time to write about how to bake that cake.

Personas are Recipes

To torture my layer cake metaphor: Personas are the recipes for how we build out a user's permissions layer cake.

Personas are not actually a technical feature of Salesforce. You can search the Setup tree all you want but—at least as of this writing— there is nothing there for "persona."

Nonetheless, personas are a useful way to organize your thinking about what you need for each user. Product design—particularly software design—is often based around the personas of the different kinds of users that might interact with a product or service. Your Salesforce implementation is no different in that regard.

Once you have figured out the personas that describe the different categories of work that people need to do, you know what combination of permissions they need. At their simplest, personas are one-to-one with job categories. Say you have:

• Executives - Mostly look at reports and dashboards.

• Fundraising Users - Enter opportunities and payments, update contact information and relationships, etc.

• Program Users - Enter program contacts, update program records, etc. (Of course, if you have many programs you could have different personas for each. But we're keeping our example simple right now.)

• System Administrators - Have access to the whole system and Setup.

Each of these personas need their own recipes to end up with the right layers.

Cross functional jobs probably constitute their own persona, but you can already see that their access will just combine the two functions that they cross. They get an additional layer of the cake.

Note that Persona, the way I'm using it, is like profiles were in the bad old (and often current) days of user management in Salesforce. So you may have a bit of persona proliferation to delineate similar roles or users with the same role on different licenses, etc.

Even if you end up with a lot of personas, we are still facilitating you moving to all profiles that are minimum access. You'll see that it's going to be easier to maintain several personas than it was to maintain several profiles.

Your user personas tell you the recipe for the cake you're going to bake. Now into the kitchen!

User Access Policies Are...The Kitchen?

[It's official: My metaphor has gotten out of hand.]

In Summer '24, Salesforce released User Access Policies. This is a handy and fully declarative Setup tool that allows you to automate granting or revoking of permission sets to users or adding users to public groups. User Access Policies are a major step toward making it easy enough for admins to get to the permissions-off-profiles future.

So let's think of User Access Policies as the kitchen, including mixing bowls, layer cake pans, stand mixer, oven, etc.

With access to a kitchen, you can turn a bunch of ingredients into a delicious multi-layered showstopper of a cake. With User Access Policies we can turn our list of personas into a fully functioning user management regime in short order. No more maintaining (usually somewhere outside of Salesforce) a flow chart of what to do when you are creating a new user. You turn that chart into User Access Policies and the work should be done—or at least mostly done—for you by the robots. That's the subject of my next post.

I don't think it's necessary for me to actually write up a How To guide for using User Access Policies. There's a Trailhead module for that.