Permission Set Group — The Next Generation Permission Management
By: Brillio Global
Tags: Salesforce, Permission

By Shankar Mallick

Salesforce released Permission Set Group in Spring’ 20. This feature has been in beta for around a year, now. Permission Set Group has added a new layer for admins to restructure how permissions can be assigned and managed.

What are the permission set group and how will they impact how admins manage permissions?

Permission Set Groups allow any number of Permission Sets to be bundled up with a new name and description. Permission Set Groups can be individually assigned to Users just like Permission Sets. This may seem like a simple new feature, but if applied properly, Permission Set Groups can revolutionize the structure of the Org.

As the name suggests, the permission set group, are a bundle of permission sets.

The traditional practice followed by Admins, earlier, would be to keep the bulk of the common sets of Permissions and setting in the Profile and assign the profile to the entire team such as Sales Team or Service Team or Operations Team. Now to extend the permission set of each user/ group of users, they would create extra permissions using permission sets and assign each extra permission set to a specific user or a group of users selectively.

Now instead of this traditional approach, Admins can tweak their strategy and opt for an alternate approach

· Admin creates custom Profiles that are relatively empty to the extent that they are just placeholders for allocating to the entire team. The majority of the functionality would ideally move out of the profiles and applied only through the permission set group.

· Move the bulk of the permissions from the profiles into smaller chunks and break it into multiple permission sets. This way each permission set is granular and does not have overlapping functionality.

· Do not assign permission sets to the users.

· Name the permission sets in such a way that they clearly give an idea of what its constituent permissions are.

· Create multiple Permission Set Group, each one mapping to every specific variation. Give them a name that can easily identify the clubbing of permissions and also identify its uniqueness.

· Now, to add the necessary functionality on each of the permission set group, identify the combination of permission sets that would be required to make it up and assign them to the Permission Set Group.

· Assign the users that map to each of these unique Permission Set Groups.

Benefits of Permission Set Group

The benefits of this approach are three-pronged:

· Flexibility: Admins have more flexibility to create as many permutation and combination of permission as possible using permission set group

· Easy Upgrade or Downgrade: Any future upgrade /downgrade of permission for any user would require just to unassign the user from an existing Permission Set Group and assign him to another without changing the structure of any profile, permission set or permission set group

· Easy Extensibility and Future proof: Whenever new custom objects, new fields, new record types, new page layouts, new tabs, new applications, etc. are created, it would not be required to make changes to the existing profiles and permission sets. Admins can add multiple new permission sets mapping to the new objects, new fields, new record types, etc, give them appropriate names and then add them to the existing permission set groups, wherever applicable.

Recommended Best Practices

· Keep the number of profiles as low as possible: It is prudent to keep the variations in profiles as low as possible and map all the Sales Team members under only one profile called “Sales Team”

· Move away from Profile: Permissions management must be done at permission set or permission set group level and not at the profile level. A few exceptions will persist for Profile because of the unavailability of Default Record Type, Page Layout, Login Hours and IP Range at a permission set level.

· Model for Role / User Task-based Permission Set Group: Permission set group should be created as Role / User Task-based as possible. This makes it easy to identify a permission set group and functionally assign it to the correct user.

· Create multiple and granular Permission Set with a set naming convention, for instance, have a Permission Set “Create and Read Accounts”, “Delete Account”. This naming convention would be better than one named “Sales Team with Delete Permission”. This way reusability in other Permission Set Groups will not create confusion.

· Model for Reusability: If you think about a Permission Sets as a modular set of extra permissions, where you will grant as many permissions as needed; you will be able to reuse them. For instance, if you followed the point above, the Permission Set in the example can be assigned to the Permission Set Group “Sales manager” and to the “marketing manager” too (if needed)