Managing Salesforce Permissions at Scale

By now most of us have heard that Salesforce announced the end-of-life for permissions on the Profile. Originally slated for January 2026, this change has been put on hold while the details are being sorted out. In the meantime, users have been left to plan how to manage permissions in a future where we can no longer base our approach on the Profile. In this blog, we outline our approach on how to solve this issue and outline the tools available to see what’s most effective.

How We Got Here

What is a Profile? Consider a Profile to be a container for permissions and access. It’s the first place we have the ability to set CRUD (Create, Read, Update, Delete permissions) for an object, access to fields, and the defaults that we want to apply to the user (things like which app they are using when they log in or their default record type). Each user is limited to only one Profile.

If you look back, you’ll see that most companies created Profiles for large sets of users who needed the same level of access. Many of us used standard Profiles to get people set up quickly, but realized they weren’t quite what we needed. As a result, we created custom Profiles and started relying on those so that the access granted was more representative of the access we needed to give. This approach worked well until we realized that of the many people we gave a profile, there was one outlier that needed more access.

Salesforce solved this issue with a tool called the Permission Set. Permission Sets are just like Profiles, except that users can have many Permission Sets and are additive in nature. A user’s access is really the sum of their Profile + Permission Sets. The Permission Set was a way for Administrators to create a small chunk of access and assign it to users across any number of profiles without over-provisioning that access. Now we had a tool that could give a user the extra access needed without creating and maintaining a whole profile.

But many administrators ended up with dozens of Profiles and hundreds of Permission Sets. User management became tedious and time consuming until Salesforce introduced Permission Set Groups, which are collections of Permission Sets that can be assigned. Several Permission Sets could be placed into a single container assigned to a user, greatly simplifying the assignment of Permission Sets. We still had too many Profiles, and far too many Permission Sets, but assigning them was a little easier.

Profile Problems

The most challenging issue with Profiles is that each user can only have one Profile. This is problematic when someone needs to perform two jobs, they’re backing up someone else, or expanding job responsibilities. Administrators are forced to create a Permission Set that mirrors the needed access from the Profile. This Permission Set is pure technical debt, and it becomes a second item that must be maintained apart from the Profile it is based on and will inevitably drift from the Profile, which may lead to issues with access.

While Profiles and Permission Set Groups have been impactful, challenges remain. In one environment, we encountered over 1,100 Permission Sets and nearly 100 Profiles. A team of 11 people had seven differing levels of access, when they were all meant to be the same. this created a much higher cost and time to manage than necessary.

The Solution

Profiles worked well initially because they took care of everything that a group of users needed. Let's call this group of users a Persona. Everyone within the Persona has the same sort of needs based on what they do in Salesforce. Note, what one does in Salesforce is often unrelated to one’s job title. A Persona like “sales user” helps define the essential levels of access across the system that are needed for sales. A Persona could easily overlap with another, like the Service Persona.

The solution starts with the Profile. The Profile is still required for every user, and it sets the defaults the user will experience. The Profile is also the only place we can set a few other things, like login hours or IP range restrictions. The Profile will serve as our foundation, but it will only be used for things that cannot be done elsewhere. It’s likely that each Persona will have their own Profile because the defaults might require it.

The next step is to create a Permission Set Group based for your Personas. Within your Persona Permission Set Group, you will have three distinct Permission Sets that build out the level of access needed. The three Permission Sets are the Base, the Read, and the Persona. Each set is broken down below: 

1. Base – The Base-level Permission Set is used in every Persona Permission Set Group and contains only those permissions that can be applied to every user. Permissions like “Lightning User” and “Can View Public List Views” work here. You will only add System Permissions to the Base, not any risky permissions. If there is any debate regarding whether a specific permission should be assigned to everyone within the Persona, it does not belong in the Base level Permission Set.
2. Read – The Read-level Permission Set includes every permission needed to allow a user to navigate their Persona’s apps without error. This means that Read for Objects and Fields, as well as access to Apps and Tabs, are added, but not the ability to edit, create, or delete. If you have components that rely on Custom Settings allowing users to see, but not interact, then those Custom Settings at the Read level can be safely added. Note, the Read-level Permission Set will cover all objects needed for an App but should not include fields that hold sensitive or risky data.
3. Persona – The Persona-level Permission Set holds everything else.

Once you build these three Permission Sets and add them to the Persona Permission Set Group, you have almost eliminated the profile problem. Super users who require two Profiles can simply be assigned a second Persona Permission Set Group. They will still be limited to the defaults established by their profile but have all of the access of the second Persona.

Let’s look at this example with five Personas. Note that the Base Permission Set and the Read level Permission Set are the same across each Persona’s Permission Set Group. This is because everyone in the organization can see the same basic Apps, Tabs, Objects, and Fields that relate to sales. Each Persona also has its own Persona Level Permission Set Group where the bespoke access has been granted. 

Long-Term Success

Migrating from Profile-based User Access to this new Persona-based approach has some clear advantages. As an example, just after implementing this approach at an organization, we learned that the company’s legal team would need access to “everything.” Providing the legal team with access was a breeze, simply by creating a new Permission Set Group for the Legal Persona and adding the Base-level and Read-level Permission Sets. The legal Persona had the ability to “see everything” considered safe without the ability to impact the data.

We should also highlight the “free maintenance” that we receive from this model. Consider a simple change like creating a new field for the sales team. They should see and be able to edit the new field. When using the Persona model, we can add the ability to see the new field to the Read Sales Permission Set and the ability to edit to the Sales Persona Permission Set. This has automatically updated the other Personas that are using these Permission Sets because the other Personas can now see the new field and are now automatically maintained.

Does all of this mean that single-task, bespoke Permission Sets are outdated? For the most part, they are. However, some things, like being a Knowledge Publisher, are not groupable within a persona and should be granted to people on an as-needed basis. But steps can be taken to ensure that these are minimized. 

We have found that a Persona-based Permissions approach is a valuable and efficient way to simplify user management and reduce the cost to manage your user base.

Learn more about our Salesforce practice.