Setting up Salesforce with permissions sets

Last year, for a client project, my team was asked to set up the entire Salesforce security model using permission sets and permission set groups – instead of with multiple profiles. This was completely foreign to me, as I had always implemented Salesforce using profiles as the primary security setup. Trying to push aside my nine years of experience was hard, but I did it – and I learned a lot of lessons in the process.

---

Permission set structure

In implementing this new security model, my team identified a way to build permission sets in logical groupings: by object groups. For instance, accounts and contacts can be clustered together, or opportunities, products, and opportunity products can be grouped. All of this setup needed to be tracked carefully on spreadsheets, so each time an object was touched – a new field added or a new related object created – we knew which permission set to add them to.

We also created a permission set for each user group that stored the general and administrative permissions to assign to these users. This allowed one place for each user group to determine what the users can and cannot do within the system. All other permission sets were object focused to maintain the object and field-level security (FLS) permissions.

Then, when it came to assigning permission sets to users, we created several permission set groups. These were done by user group, so the permission sets could easily be bundled together. For example:

• Sales
• Sales Manager
• Finance
• Customer Service

Users were then assigned at the permission set group level, rather than via permission sets directly, allowing for easier administration.

We used a spreadsheet to track all the object and field-level security (FLS), and which ones were assigned to each user group, in the following ways:

• Permission sets to objects – which objects were in each permission set
• Permission sets to permission set groups – which permission sets were in each permission set group
• Permission set FLS – for each object in the permission set, which fields were editable and read only

---

Limitations

Through this process, our team identified several items to be aware of for future implementations.

• When creating a new field, Salesforce asks you which profile(s) you want to add the field to – this is now available for permission sets but in a limited capacity (you cannot add to both permission sets and profiles once you toggle the feature on).
• You cannot create a permission set without a license designation if you want to enable tab visibility through the permission set. This option is disabled without a license type selected. This means if you have two user groups that will have the exact same object assignment and FLS applied to them, but different license types, you must create two different permission sets for them to assign the tabs of those objects. And permission sets with licenses assigned cannot be cloned to use for a different license type; you must manually set up the second permission set with all the same options. Depending on your requirements, this could become very cumbersome. Hint: there’s a really cool AppExchange tool, Mass Assig Permissions, that can assist with this – but some manual steps are still required.
• Some managed packages are not set up to read permissions through a permission set group, only through permission sets. This introduces an extra layer of user maintenance to assign users at the permission set level for those specific packages, in addition to the permission set group.

---

Summary

Managing security through permissions sets is where Salesforce is headed – and encourages its partners and customers to focus. While the limitations listed above can introduce some complexity, it’s worth spending the time and effort to move toward this security model. The time is nearing – Salesforce has already set a date for when Profile FLS will be sunset – a spring ’26 release!

When you embark on this journey, do think through your permission set design – what is the least common denominator to create a permission set that is shared across the greatest number of users? Then layer on top of that for additional functionality. Your standard objects and fields should be at the lowest layer possible. Permission sets and permission set groups are built to enable a packaging structure; start thinking in terms of features and job functions as you’re building out your Salesforce solution.

Note that there is a tool to migrate profiles into permission sets, but use caution. You may end up with a very large permission set made up of everything from a given profile. It will not follow the model discussed above.

I’d love to hear your thoughts on the permission set-focused security model. What has worked well for you?