Last year, my team was tasked with setting up the entire Salesforce security model for a client project using permission sets and permission set groups instead of the traditional use of multiple profiles. This approach was completely new to me, as my previous Salesforce experience had always revolved around profiles as the primary security model. It was challenging to put aside my nine years of experience, but I pushed through, and in doing so, I learned valuable lessons.
Permission Set Structure
During the implementation of this new security model, my team came up with a logical approach to structuring permission sets in object-based groupings. For example, we grouped accounts and contacts together, or opportunities, products, and opportunity products could be bundled. This required careful tracking on spreadsheets, so each time an object was updated – such as adding a new field or creating a new related object – we could easily determine the appropriate permission set to assign it to.
We also created a central permission set for each user group to store general and administrative permissions. This served as a one-stop solution for defining what users could or couldn’t do within the system. The remaining permission sets were object-specific to handle object and field-level security (FLS) permissions.
When it came to assigning permission sets to users, we created permission set groups by user group. This allowed for easier management by bundling permission sets together. For example:
- Sales
- Sales Manager
- Finance
- Customer Service
Instead of assigning permission sets individually, users were assigned to the appropriate permission set group, simplifying administration.
Tracking and Administration
We used spreadsheets to track the object and field-level security (FLS) assignments, which included:
- Permission Sets to Objects – Identifying which objects were in each permission set.
- Permission Sets to Permission Set Groups – Mapping which permission sets were part of each permission set group.
- Permission Set FLS – For each object in the permission set, specifying which fields were editable and which were read-only.
Limitations
While implementing this model, we encountered several limitations worth noting for future projects.
- Field Assignments: Salesforce allows you to specify which profile(s) a new field should be added to, but this functionality is now available for permission sets, albeit with limitations. You can’t add fields to both permission sets and profiles once you enable the feature.
- License Designation: When enabling tab visibility through a permission set, you cannot create a permission set without a license type. If you have two user groups with identical object assignments and FLS but different license types, you’ll need to create separate permission sets for each. Moreover, permission sets with licenses assigned cannot be cloned for a different license type – manual setup is required, which can be cumbersome. Fortunately, tools like Mass Assign Permissions on the AppExchange can help, though manual steps are still necessary.
- Managed Packages: Some managed packages do not support permission set groups and can only read permissions through permission sets. This requires additional maintenance to assign users at the permission set level for these packages.
Summary
Salesforce is clearly moving towards managing security via permission sets, and they’re encouraging customers and partners to adopt this model. While the limitations mentioned above can add complexity, it’s worth investing the time and effort to transition to this approach. Salesforce has already announced that Profile FLS will be deprecated in the Spring ’26 release.
As you plan your transition, think carefully about your permission set design. Consider the least common denominator for creating permission sets that can be shared by as many users as possible, then build on that for additional functionality. Keep your standard objects and fields in the lowest layer possible. Remember that permission sets and permission set groups are designed to facilitate a modular packaging structure, so think in terms of features and job functions when building your Salesforce solution.
Lastly, there is a tool to migrate profiles into permission sets, but use it cautiously – it may end up creating large permission sets that encompass everything from a profile, which doesn’t follow the model outlined here.
I’d love to hear your thoughts on the permission set-focused security model. What has worked well for you?
