Why you should move to Salesforce Permission Set Groups

Note: In this article, a “permission” will refer to the specific access granted to an object, field, or other metadata, for example, “read” or “edit”. A “permission controller” is a Profile, Permission Set, or Permission Set Group that does the actual granting of permissions.

Current practice is to grant user access to metadata and data through a combination of Profiles and Permission Sets. Originally, a Profile was the only mechanism to grant permissions to a user. Profiles were generally associated with a job function in the organization. But if some users in a role needed slightly different (typically, additional) permissions, then the choices were:

• Create a new Profile, resulting in an explosion of highly-overlapping Profiles with unnecessary object permissions and field permissions.
• Clone an existing Profile and make a few changes, also adding to the problem of highly-overlapping Profiles with misaligned profile-based permissions.
• Update the existing Profile, resulting in over-permissioning some users with excessive permissions for profiles that go beyond the necessary custom permissions for their job function.

The lack of analysis tools made it difficult and time-consuming to identify what a Profile could access and to understand the differences between Profiles and profiles into permission set conversions.

The introduction of Permission Sets allowed an additional, fine-grained way of granting custom permissions and field permissions. This was good for defining access required for a specific task, such as managing app permissions and Connected app access, but did not address the fact that only Profiles provided an easy way to group permissions for a job function. Permission Sets were often used for access to new features. However, the lack of tools made it difficult to prioritize cleaning up user profiles and managing profile-based permissions within user management settings. Therefore, the twin issues of overlapping permission controllers and over-permissioning users only got worse.

With the introduction of Permission Set Groups, Salesforce are advocating a security model redesign using a combination of:

• Permission Set Groups: The primary permissions grouping mechanism. A Permission Set Group is a grouping of Permission Sets, ideally organized around a specific role, job function, or jobs-to-be-done. Unlike all other permission controllers, which can only grant additional permissions to a user, a Permission Set Group can remove permissions via a Muting Permission Set, improving Control Access and Access management.
• Permission Sets: A Permission Set is a task-based grouping of permissions, which could include object permissions, field permissions, and app permissions. Ideally, a Permission Set contains all the permissions necessary to perform a well-defined task, including the associated Flows, Apex Classes, Objects, Fields, and Connected app access.
• Profiles: In this new security model, the only remaining job of a Profile is to define the allowed login hours, login IP address ranges, and default apps and record types.

The target security model you are aiming for is:

	Current state	Target
Profiles	Many, Overlapping permissions	Few
Permission sets	Many, Inconsistently-defined	Many, Task-based
Permission set groups	Minimal / none	Many, Role-based

When you apply this approach to user permissions in a planned and structured way, it improves security and reduces admin overhead. The benefits are:

• Easier to provide the correct level of permissions to any individual based on job function by using Profiles and Permission Sets.
• Reduce accidental over-permissioning, by managing individual permissions.
• Simplify troubleshooting of access management problems, related to custom permissions, object permissions, field permissions, etc.

A recent Change Intelligence Research Report on security has revealed a concerning level of unintended access due to multiple permission controllers providing similar access – on average 60 permission controllers with an 80% overlap for Account and Contact object permissions. The average across all standard and custom objects drops to 18 and 70% respectively. The report also identified that 30% of permission controllers provide the full levels of level of permissions – “Create, Read, Edit, Delete, View all, Modify all”. This makes it very difficult to revoke access and control field permissions or custom permissions.

This is why Salesforce wanted to provide Permission Set and Permission Set Group features and guidance on how to migrate to a more secure and streamlined model. They stopped going as far as retiring permissions on Profiles with the Spring’26 release, but there is still a strong business case based on security risk to migrate immediately. Organizations need to transition from profile-based permissions and manage custom permissions, field permissions, object permissions, and app permissions through Profiles and Permission Sets to ensure a better approach to user permissions and more efficient access management.

The challenge with migrating to the new security model is unpacking the complexity of access provided by multiple permission controllers for any user. This needs to be seamless, so that users are allocated the minimum individual permissions required to perform their job function, but it does not disrupt them by inadvertently taking away the access they need through Profiles and Permission Sets or affecting access management.

Prepare to uncover some ugly workarounds. What seems a simple change in access could impact legacy automations relying on the permissions of the user who triggered the process. Automated reports and dashboards that rely on the user’s access to certain data might not generate correctly, leading to incomplete or incorrect data being displayed. If email alerts or notifications are configured to be sent based on the user’s individual permissions, removing those permissions might prevent these alerts from being sent or cause them to contain incomplete data. These shouldn’t be reasons for not migrating. The new security model, with its streamlined Profiles and Permission Sets and more efficient access management, will be much easier and safer to manage. And, bear in mind you need an easier security model to manage as you think about Data Cloud and Agentforce.

There is a proven approach to migration, and Elements has developed sophisticated permission analysis to be able to plan and execute the migration. Salesforce developed this alongside its own analysis tools. Elements provides deep, granular reporting – field access by user-based permission controllers and permission controller comparisons – that is impossible on the platform based on the volumes of data.

Permission Set Groups replace Profiles

Profiles used to provide all the access that a user needed to access Salesforce. Therefore they became unwieldy with a long list of access controls. They were typically tied to one or more user profiles. But if a new user required a slightly different access, the closest profile was cloned and then additional permissions were added. This means that the user was probably allocated permissions they didn’t need and shouldn’t have, because removing permissions from the profile was too time-consuming. An alternative approach was simply allocating more Profiles to the user to provide the access required. Again this often allocated permissions that were not needed.

The change is that the Profile now should only provide baseline authorization of access for all users of a particular type. And user should only be allocated to one Profile.

Permission Sets should replace Profiles for providing specific object-level access. There could be several Permission Sets for an object because they each provide different levels of access. For example: one could have Create, Read, Edit but another could simply be View.

This provides far more granular permissions, and a more transparent security model.

The business case for the move

Salesforce #1 value is Trust. They provide the tools to enable organizations to lock down the security of data limited to just those who need access to it, ensuring access is limited to those with the appropriate custom permissions, field permissions, object permissions, and app permissions. However, the current user management settings and permission structures that we see in organizations often fall short. They open organizations to security breaches and data loss due to mismanaged Profiles and Permission Sets and inadequate Control Access systems.

These may be accidental or bad actors with access to data that they shouldn’t have:

• A user modifying or deleting data.
• A user able to see data they shouldn’t.
• A bad actor that is leaving exporting data to take with them.
• A bad actor that is a disgruntled user deleting, modifying, or exporting data.

Enhanced security and compliance

Regulatory compliance like GDPR and CCPA has emphasized the importance of data governance. And every organization has strict policies on data to protect their IP and customers. No longer is it just highly regulated industries like food, pharma, healthcare, and financial services. Every industry has data regulatory responsibilities. Security breaches, due to mismanaged Profiles and Permission Sets or user management settings, impact reputation and in the worst cases incur fines. There cannot be a stronger business case than, “we need our data to be secure”.

Organizations are now looking at the potential of Data Cloud to aggregate data. Aggregating data can raise the security level above the security level of the individual siloed data. This is because of the additional insights offered by the aggregated data.  For example: the airforce has the individual datasets – aircraft maintenance status, availability of repair parts, the schedule of maintenance, aircrew availability. Each dataset has its own field-level security and base permissions, but together they provide a picture of the fighting capability, which has a significantly higher level of security. No Data Cloud implementation should ignore a review of the security measures, so there is robust data governance.

Agentforce has put a huge focus on the quality of data. Giving users access to modify data that they don’t need, such as unnecessary custom permissions, field permissions, or object permissions, puts data governance and data quality at risk. This is not a major driver, but should be a consideration. It is also the project that can trigger a review of the security model.

The move to a more transparent, easily maintained security model provides users with the permissions – including connected app access, profile-based permissions, and individual permissions – that they need to fulfill their job function. At the same time, you can consider whether to apply encryption standards.

You should not delay this project. Do not wait until you fail the next compliance audit because you do not adequately support the compliance protocols. The good news is that it does not have to be big bang. You can deliver it in a phased approach without disrupting users. Done properly, they will have no knowledge that it is happening.

Simplified user management

This may seem like a project that is a huge amount of undervalued work. It is true that the benefits will not be visible to end users who are demanding more functionality. But this is critical, architectural, tech debt work that will simplify future user management. You can point to security compliance to justify starting the project. However, once you implement the new security model, you will streamline user management. You will work with permission controllers that have fewer custom permissions, field permissions, object permissions, and profile-based permissions, making them easier to understand and manage. making them easier to understand.

The principles are:

• A large number of users are allocated to each Profile, and a user is only allocated to one Profile. Profiles should have only the baseline permissions.
• Permission Sets provide limited access so there will be a large number of Permission Sets. 
• Permission Set Groups that are built to support different roles. These provide the targeted permission level of access because they combine the correct Permission Sets. 
• User permissions to any object are provided through one or a small set of permission controllers that have no overlaps.
• Minimize the users who have “dangerous system permissions”. These grant system-wide, as opposed to object-specific, access to perform critical actions such as Modify All Data, Export All Reports, or Manage Users.

This approach improves security and reduces admin overhead. The benefits include:

• Easier to provide the correct level of access to any individual based on role.
• Reduce accidental over-permissioning. 
• Simplify troubleshooting of access problems.

Security scenarios

So there is a business benefit to reworking the security model. Like any tech debt reduction project, the benefits are future productivity. By optimizing Profiles and Permission Sets, managing custom permissions, field permissions, and object permissions, and ensuring proper Control Access, you can improve the overall security framework. Let’s look at the different scenarios and compare the current situation with the new world, where streamlined user management settings, permission assignments, and the level of permissions are better aligned with job functions:

New user: Instead of wading through large numbers (on average 18-60) of different permission controllers to decide which to allocate (or clone and modify) to a new user, you simply select the Profile and the Permission Set Groups that apply. If none are perfect due to a new job function, you can create a new Permission Set Group by building it from the constituent Permission Sets, ensuring the correct custom permissions, field permissions, object permissions, and app permissions are allocated. This provides a more efficient approach to user permissions, streamlining permission assignments.

User changing role: This is typically hit or miss. When a user changes their job function and needs new permissions, you add new Profiles and Permission Sets to try and allocate the access they need. It is difficult to remove access they no longer need because it could mean removing a large number of overlapping permission controllers. This runs the risk of removing individual permissions or profile-based permissions that the user still requires. With the new model, you simply remove the permission assignments for the old role and add the appropriate custom permissions, field permissions, object permissions, or app permissions for the new role.

Removing user access: A compliance audit, data breach, or data loss highlights that certain users need access rights removed from certain objects. Analyzing this is a nightmare because there could be a large number of overlapping permission controllers that provide access to the object permissions. You will need to remove all the permissions that grant access to the object. If you don’t remove them all, then the access is provided by the others. But then you will need to work out how to reapply permissions to the other objects, that they need to do their job. In the new world, you simply create new Permission Sets and allocate them to the Permission Set Groups that need the access. 

Extending access: As roles change or new functionality is rolled-out, the access rights for users need to be extended. Again, with a large number of overlapping permission controllers, you need to decide which of them to add the new custom permissions, field permissions, object permissions, or app permissions to, based on the different user profiles and job functions that need access. Ensuring the correct permission assignments is key to managing Profiles and Permission Sets, and avoid over-permissioning.

Analyzing why a user has/doesn’t have access to an object: This means wading through the 50+ permission controllers to understand the access. So this is a thing of the past. The transparency means that it is immediately clear why access is granted.

Migrating from Profiles to Permission Set Groups

This will probably feel like a scary, high risk, low-reward project. That is why you keep putting it off. So we’ve come up with an approach that is both phased and achievable.

Step 1: Clean up Profiles

Create the default Profiles with minimum permissions.

Strip the permissions from the existing Profiles and create unique Permission Sets. We will not reuse the existing Profiles, but we will mark them for deletion without taking them away from users yet.

Step 2: Consolidate Permission Sets

Compare the access granted by the existing Permission Sets. Consolidate those with overlaps into a number of discrete Permission Sets.  Again you cannot delete the old ones yet, but mark them for deletion.

Step 3: Design Roles and create Permission Set Group 

Look at the roles in your organizations and for each role, identify the permissions that they require. For each role create a Permission Set Group.

Step 4: Allocate Permission Sets to Permission Set Groups

Now you can allocate Permission Sets to Permission Set Groups. You need to confirm that the permissions in each Permission Set Group, support the roles, but that there is no over-permissioning. You may need to create additional Permission Sets. 

Step 5: Allocate users to Permission Sets Groups

Allocate the users to the Permission Set Groups based on their roles.

Step 6: Allocate users to Profiles

Allocate the users to the Profiles based on the baseline permissions that they need.

Step 7: Remove Profiles and old Permission Sets

You should be able to safely remove the Profiles and unused Permission Sets from the users. If you have got it right, they won’t even notice. 

Step 8: Troubleshooting

Users may find they don’t have access to items that they need.  This could be for a number of reasons:

• They don’t need access based on their role, but they used to have access. “You only miss it when it’s gone”.
• They need access for their role, which means other users with that role also need it. So you need to go back to the Permission Sets in the Permission Set Group and decide which one needs access. This may be by adding a Permission Set to the Permission Set Group or maybe you need to create a new Permission Set and add it to the Permission Set Group.
• They have another role, and therefore they need to be allocated to another Permission Set Group.

How Salesforce and Elements support you with the transition

Cheryl Feldman (Salesforce PM User Management) has a strong vision for the future of user management, and her team has worked hard to deliver the new permissioning functionality. They have also provided high-level analysis and they have an ambitious roadmap of much-needed views into permissions data. Check out the session on “The future of user management” from Dreamforce 2024.

For very detailed permissions analysis, we’ve worked with her team to provide the Elements Permissions Explorer capabilities. This dovetails with, rather than competes with, the Salesforce functionality. For example, the detailed field-level analysis can have millions of rows of data, so this is really only possible off-platform in Elements. In combination, the Salesforce and Elements functionality supports your migration to the new security model as painlessly as possible.

Final word

There are many good reasons for moving to the new security model using Profiles, Permission Sets, and Permission Set Groups: more secure data governance, reduced admin effort, and improved security transparency. However, the project will require work to unpick years of work-arounds and technical debt, particularly with regard to custom permissions, field permissions, object permissions, and app permissions. Business users may not see immediate benefits, but the earlier you start managing user profiles and user management settings through the new model, the sooner you will get to the benefits. You can delay this project indefinitely; until a major security breach forces action, of course. And then it is panic stations.

You need to find compelling reasons that the business understands to initiate the work. The easiest is regulatory compliance. But, the business’ aspirations to securely implement Agentforce and Data Cloud is a close second.

6-12 months ago the migration would have been almost an impossible task. Now the combination of Elements and Salesforce tooling makes it achievable. What are you waiting for? A data breach?