Use Permission Sets To Overcome Common Access Dilemmas

As an Awesome Admin, it’s probably in your nature to look for any way to optimize a process or situation! As part of that never-ending desire for optimization, I would bet that you’ve spent a lot of time thinking about your permissions setup in Salesforce. Salesforce provides multiple ways to grant permissions to users, each with their own advantages and limitations.

One of the most common limitations that admins face is the “single profile dilemma,” where each user can only have one profile. As an example, the scenario outlined below highlights why things get tricky when all permissions are housed in profiles. In this post, we’ll evaluate how we can use other tools like permission sets and permission set groups to establish a new permissions model that solves this problem and has other added benefits.

Let’s set the scene: You’re an admin with a user, Astro, who mostly works with the Sales group, but they also cover a few Marketing-related tasks. You have a Marketing user, Codey, who is heading out of the office to go on tour with his band, and Astro needs to cover his work for a few months. With this knowledge, you head to Setup to provision permissions to allow Astro to complete this work.

What options do you have?

1. Profile: Users can only have one, but this is where any defaults are assigned.
2. Permission set: Users can have many, but defaults can’t live here.
3. Permission set group: Users can have many, and they can be set to expire.

Even though your org already has a Sales profile and a Marketing profile, this doesn’t help Astro because they can only have one assigned to them. Do you make a new profile just for Astro? No, we can do better than that! Let’s explore how we can create a better solution, not only so that we aren’t managing an entire profile for one user, but also to set up a permissions architecture that utilizes reusability.

Personas

In order to refactor permissions, we have to understand what users are doing with their permissions in Salesforce. What a user spends their time doing in Salesforce describes their persona. Consider the comparison of Marketing, Sales, and Service personas below.

Astro, from our example, fits into the Sales persona because they’re focused on things like leads and opportunities and work with processes involving Sales objects. The Sales persona might also view campaigns, which is one permission that might overlap with Marketing. Astro can also transfer cases as part of their customer and account management work.

When we understand personas, we can start to identify where users share permissions. We end up with three buckets.

1. Permissions that everyone needs
2. Permissions that can be shared between certain personas
3. Permissions that are specific to one persona

This becomes the basis for a three-part Persona-Based Access Model.

Tip

Querying for your permissions can be a helpful tool when trying to understand your org’s permissions. You can find more info on Salesforce queries here. The View Summary feature related to profiles, permission sets, and permission set groups is also very helpful for understanding permissions.

SELECT Field, PermissionsEdit, Permissions Read, Parent.Label
FROM FieldPermissions
ORDER BY Field

SELECT SobjectType, PermissionsCreate, PermissionsDelete, PermissionsEdit, PermissionsRead, PermissionsModifyAllRecords, PermissionsViewAllRecords, Parent.Label
FROM ObjectPermissions
ORDER BY SobjectType

Persona-based access

We can fit most (see below for notes on flexing with this model) permissions into these buckets.

1. Base permission set

The foundation of every user’s access. A collection of system permissions that are ubiquitous. Very-low-risk permissions belong here.

It includes things like:

• Run flows
• Lightning Experience user
• View public list views

2. Read permission set

A collection of Read Only UI-centered permissions that give access to a view of the business. There is moderately more risk associated with these permissions.

It includes things like:

• Apps
• Read for an object
• Read for a field
• Custom permissions that allow Read on LWCs

3. Persona permission set

Anything else. The permissions with the most risk belong here (for example, encrypted fields, personally identifiable information (PII), etc.).

It includes things like:

• Edit, Create, Delete anything
• Other system permissions

Then, each persona has a permission set group that contains one of each of those three types of permission sets.

If we consider the diagram above that highlights the shared permissions between groups, we might end up with a model like this. We start with an empty profile that contains only what has to be there (for example, default record types, default layouts, etc.). From there, everyone shares the “Company Base,” while Sales and Marketing share “Sales Read,” and each persona has its own “Persona” permission set.

From the example, Astro would be assigned the Sales permission set group. Within that group, The Company Base permission set enables them to log in during set hours, run flows, use Lightning rather than Classic, and perform other functions that everyone in their org can do. The Sales Read permission set gets more specific, enabling Astro to view everything they need to in order to complete their tasks in Salesforce. Astro can do things like view leads and opportunities and use the Sales app. Finally, the Sales Persona permission set is the most specific and allows Astro to create and edit leads, convert leads, and edit opportunities, for example. The combination of these permission sets creates a package of permissions that means Astro can crush all of their Sales goals.

Flexing this architecture

Just as you flex Sales Cloud or Service Cloud to fit your org’s needs, the same goes for this model. Some permissions, like things related to Knowledge Publisher or Experience Cloud, may not fit cleanly into this setup—and that’s okay!

Ways I have flexed this model:

• Using naming conventions to specify permissions that are assigned outside of this model; for example, “Non-PSG — Login to Experience as User”
• Differentiating a Company Base Internal and Company Base External to allow reusability while ensuring external users, like Experience Cloud users, have appropriate access
• Sharing the Read permission set across users who use the same app and therefore the same objects and tabs

Other advantages, considerations, and tips

Is this permissions architecture sounding like something you can’t wait to implement? Great! To add icing on the cake, here are some additional benefits of this model.

1. Save your backlog

Let’s consider a user story from the Sales team.

As a Sales User, I can track an Account’s region so that I know which products are relevant. With the Persona-Based Access Model, I know right where Field Level Security (FLS) permissions need to be.

• Read FLS → Sales Read permission set
• Edit FLS → Sales Persona permission set

With the example used above, Marketing shares the Sales Read permission set which means we’ve also granted Read FLS to that group, and they never had to ask! They can see this new field and maybe use it to inform new campaigns.

2. Stay organized

Naming conventions are helpful with this model. I like to use the format below so that when I’m looking at Permission Set List Views in Setup, everything is nicely sorted.

• • Base — Internal
  • Read — Sales App
  • Persona — Sales

3. Track simpler metadata

If you’re using a repository to track your metadata and you’ve ever looked at a profile, I bet your eyes glazed over after a few seconds. Profile metadata files are long, and they track everything—not just the additive permissions. Permission sets only track additive permissions (for example, permissions where at least one attribute is “true”). This makes the files much shorter and easier to digest and manage.

Solve Astro’s permissions dilemma and bring persona access to your org

So, how does this solve the permissions dilemma that Astro is facing? Simple: We can assign Astro the Sales permission set group for their usual work and then also assign the Marketing permission set group to cover for Codey. We could even set the Marketing permission set group to expire after Codey’s band’s tour is set to end.

Let’s review how you make this happen in your org.

1. Identify your personas

This part of the process is where the bulk of the work lies. If you have a business analyst on your team, they might be a big help in understanding the permission setup you have in present state. Use the tools mentioned in the Persona section, and see if your BSA can help with the analysis once you have data to work from.

2. Transition permissions to their relevant new permission set

Moving permissions from one permission set or profile to another permission set is easiest when you’re working directly with the metadata in VSCode. You can essentially build the permissions out in the Permission Set file using some crafty copy-paste and then deploy that to your Sandbox org. Do not make these changes directly in production. Additionally, there are some profile-to-permission-set tools out there, including Salesforce’s Converter tool in Setup.

3. Audit

The tools mentioned in the Personas section above are also very helpful when it comes to auditing your new architecture. If you have the analysis from when you started, compare it with a similar analysis after you’ve refactored.

For what it’s worth (although this isn’t really why you should refactor permissions), one org that I transitioned to this model went from 230+ permission sets to 30. Maybe that’s the spark you need to hit the ground running at your org. You’ve got this!

Resources

• Salesforce Admins Blog: Admin Best Practices for User Management
• Salesforce Admins Podcast: Reduce Salesforce Profiles for Greater Efficiency
• Salesforce Admins Blog: How to Set Assignment Expiration on Permission Sets and Permission Set Groups