My team and I are currently looking for the best way to manage permission sets. Each permission set adds overhead in development and testing. Ideally we would provide the minimum amount but as development goes on, arguments are constantly being made for more sets. One option we're considering is have a permission set for each feature set and then using Permission Set Groups to group them by Persona.

This means overall there would be more permissions sets but maintenance and upkeep will be more straightforward as the changes will only be in one place. This should also eliminate inconsistencies between permission sets and allow endless configuration in groups.

Wondering if anyone else uses a similar approach or any obvious pitfalls?

2 Answers 2


I would argue that is the intended purpose for Permission Set Groups. You can see the following slide from this video on an Admin's Guide to Profiles and Permissions when Permission Set Groups was released in pilot.

enter image description here

You'll see the vision with Permission Set Groups is Role Based User Access Control. Within that slide, they associate Permission Set Groups (PSG) with job roles and Permission Sets (PS) with tasks.


  • Naming convention - as you noted, this will lead to more permission sets/groups. Having a set naming convention will help those creating new ones as well as those responsible for assigning them to users
  • What will be in your profiles? There's the more drastic cutover where you consolidate profiles into one "minimum access" profile, but you can start utilizing your idea for specific features/tasks and slowly chip away at your profiles over time.


  • Permission Sets will allow you to abide by the principle of least privilege, but only if you use them as intended once it's built out. Don't fall into the trap of behaving like profiles - ex. giving users the permission set group instead of the one specific permission set for the task. It requires more thought and consideration when responding to user permission requests
  • There's still some things that permission sets can't handle (ex. Layout assignments) so it's difficult to make a complete switch over. Newer features like dynamic forms give you more ways to change the UI view per user, but that only applies to custom objects currently.
  • When you create new fields, you now have extra screens to ensure the relevant Permission Sets have access to the field. Salesforce only displays Profiles for field-level security (FLS) setup when creating a new field. See this idea for hopefully providing permission sets in that setup screen as well to ease this pain.
  • 1
    well said; one would like to see the "add a custom field" UX make it easier to add the FLS to specific PS(s)
    – cropredy
    Jul 27, 2021 at 18:46
  • 1
    good point! I added in a quick edit and plug for the idea Jul 27, 2021 at 18:49
  • Thanks for this @KrisGoncalves. Really comprehensive answer. As of yet we haven't gone down this route but as we go there're more and more reasons to so your answer will definitely be helpful when we do.
    – Shane Bird
    Aug 13, 2021 at 16:32

By Role, I presume that you mean Personas. And I would agree with this implementation. Each Permission Set should encompass a single feature, and each Permission Set Group can encompass a Persona, which makes it easier to identify a user by their Persona, and thus what features they have access to. Further, this means that implementing new features will allow you to assign that feature to whichever Personas you need to assign the feature to all at once. As you noted, there's a bit more metadata to manage, but the end result should be more maintainable.

  • Yes @sfdcfox Personas was the correct term and I have updated the question to reflect so thank you for that. Thanks as well for the answer, I believe the sooner we get into this habit the better so I will bring the case to the team soon. Thanks again!
    – Shane Bird
    Aug 13, 2021 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .