Permission Sets – Custom, Groups and Muting in Salesforce

Permission Sets – Custom, Groups and Muting in Salesforce

Profiles are used to provide a minimum level of permission to users based on the Principle of Least Privilege. There are a lot of scenarios where users in the same profile require additional permissions or lose existing permissions. This level of mutually exclusive permission requirements within a profile needs to be managed by creating multiple profiles with different permissions.

Permission sets, introduced in 2012, were seen as a convenient way to overcome this issue.
The advantages of permission sets are listed below

Assigned at a granular level to users.
Independent of the user profile.
Provides just-in-time access elevation.

Let’s explore the use of this with a scenario.

Requirement :

Two users, Amy and Bob, belonging to the Support profile.
ABCompany_CC object exists to track the complaints of customers.
Amy from the customer support team needs to see fields: Prior History, Warranty amount, Warranty status, Pre-condition.
Bob from the technical support team needs to see Damage Details, Pre-condition, Spare availability.

Possible Solution 1 :

Providing view access to all the mentioned fields on the profile level.
Answer: Not Recommended.
Amy and Bob would see fields they do not have to see on the ABCompany_CC object.

Possible Solution 2 :

Change the FLS on support profile according to Amy, create a new support profile-2 with FLS requirements of Bob.
Answer: Not Recommended.
For every new request, a new profile has to be created or multiple profiles have to be edited to suit.

Possible Solution 3 :

Remove all the FLS from the Support profile. Create two new permission sets customer support and technical support and edit the FLS requirements for Amy and Bob accordingly.
Answer: Makeshift solution. Adopted.
Why is it a Makeshift solution you ask for?
Let’s say a new user, Cathy is onboarded on the Sales profile and needs to see Damage Details and Warranty Status fields only.
In such a scenario, ideally, the admin is asked to create/clone a new permission set.

Here’s why that’s an issue

The creation of permission sets would become a never-ending job for admins. One can only attempt to fathom the ocean of permutations and combinations that arise when multiple users of different profiles and roles want different levels of permission on system, fields & objects.
Every time a request comes in to provide additional permissions, admins have to scan through the lists of existing permission sets to see if it already exists. Even if it already exists, what if the permission set gives permissions that are additional to the ones needed? This fear drove admins to create new permission sets in such cases.
During every maintenance phase, admins have the tough job of reviewing/auditing the permissions to prevent privilege leakage and security breaches. Remember to maintain a separate Excel sheet with Object Relationships, CRUD, and FLS.
The number of profiles reduced, but the number of permission sets piled. At some point, permission sets became as hard to maintain as profiles.

Permission Set Groups :

Spring’20 release treated Admins with Permission Set Groups as GA.

A permission set group streamlines permissions assignment and management.
Use a permission set group to bundle permission sets together based on user job functions.

Provide a way of logically bundling different permissions based on a user’s job.
Applies all the combined permissions inside the permissions sets to the assigned users.
Has a many-to-many relationship with Permissions sets.
Contains a maximum of 100 permission sets.
Can have a permission set to be part of multiple groups.
Needs to be maintained, but not as tedious as maintaining multiple profiles or permission sets.
Let’s explore the use of Permission Set Groups with a scenario.

Requirement :

ABCompany is up for its first internal audit next week, and every department staff needs to analyze and maintain only relevant active records.
Users in the Support and Sales department share the same level of permissions on many objects and system.
Every department has maintenance staff who have the tough job of going through several reports and weed out stale records from the system.
Salesforce Admin is asked to help maintenance staff in audit preparation and ensure necessary accesses and permissions for all users.

Objects :

Sales Metrics Audit
Support Cycle
Sales coverage
Warranty Entitlements
Product performance measures

After careful consideration, Admin creates three Permission Sets with CRED access as below :
Audit: Sales Metrics Audit + Sales coverage objects
Metrics: Product performance measures objects
Analysis: Support Cycle + Warranty Entitlements objects

One Permission Set Group is created with the name Departmental Staff containing Audit + Metrics + Analysis. This permission set group is assigned to the department maintenance staff to ensure they have the required permission on the objects.

Suddenly, with just two days remaining, Admin is assigned the task of creating RO permission for all the objects listed above for a new set of Audit users. Admin is also instructed that whenever a new object permission/ system permission is added to any of the permission set listed above, the audit users must automatically get RO permission to those object as well(Future Proofing).

An Admins first impulse would be to create a new profile and permission set just for audit users an ensuring all the permissions and FLS get carried over from the Departmental Staff group. The catch here would be that the admin has to update the new permission set every time a new object/system permission is added to the group. There is no ease of maintenance here.

What if there was a new set of users Junior Staff Analyst who want all the object CRED from the Departmental Staff permission set group but not any of the system permissions?

What if we could assign the Departmental Staff permission set group to the audit users and also provide RO permission to them?

There’s one answer to both the questions.

Muting Permission Sets:

Let me introduce you to Muting Permission sets. They are a way of muting/disabling permissions within the permission set groups.

In the above scenario, to view all the Combined permissions from all the permission sets on the Departmental Staff permission set, admin opens the permission set group and views the permissions categorically. This helps Admin to understand the cumulative permissions provided by the permission set group and that is key while creating a muting permission set.

Admin goes through the combined permissions and identifies what object CRED and system permissions needs to be muted. The Next step is to open the permission set group to see muting permission set menu item. Admin creates a new muting permission set from here. On selecting say system permissions or object permissions, the Admin can see combined permissions on the permission set along with a new checkbox column called Muted. Select the checkboxes in this column to mute/disable the permissions. It is as simple as that.

Let’s see some gotchas/considerations about muting permissions via permission sets.

Muting permission sets are possibly one of the only ways to restrict the permissions within Salesforce.
Muting permission sets are part of Permission set groups only.
Only one muting permission set is allowed per Permission Set group.
Muting permission set is also unavailable as an assignable permission set outside the group.

5. Dependencies

Combined Permission	Muted Permission	What happens?
CRED + View and Modify All	Read	All permissions are lost
CRED + View and Modify All	Edit	Edit, Delete and Modify All
CRED + View and Modify All	Delete	Delete and Modify All
CRED + View and Modify All	View All	View All and Modify All

6. User permission dependency

Let’s say a group of users having a permission set group Maintenance can Merge duplicate leads. An Admin after careful consideration decides to disable the users Edit permission on lead object. So, a new Muting permission set is created, Mute Maintenance with the Edit permission on Leads removed. To merge leads, only Read and Delete permission is needed. So, removing Edit permission shouldn’t be a problem right?
Unfortunately No!
Check the Dependency table in the previous point. When Edit permission is muted, Delete permission is lost along with it and the users can no longer Merge leads. This implicit lose of permission needs to be accounted when core object permissions are changed.

With all this being said, one must view profiles as just a placeholder for core configurations like record types & page layout assignments. Permission sets, groups and muting permission sets can be used to create a mixture of role-based permissions which are scalable, flexible, robust and lasting.
Here’s my recommendation if you are starting up with permissions :

Clone the Minimum Access Profile and assign the least privilege on objects; and configurations that a permission set cannot provide.
Use Permission sets for user’s atomic job functions/ tasks.
Use Permission set groups for grouping all the tasks a particular job function may need.
Use muting permission sets whenever a particular permission set group needs to lose a specific permission.

Schema details :

PermissionSetGroupComponent – Junction object between PermissionSet and PermissionSetGroup objects.
PermissionSetAssignment.PermissionSetGroupId = PermissionSetGroup.Id (Field used to assign a permission set group to user)

Metadata Types :

Profile – Profile of users.
PermissionSet – All Permission sets created in the org.
PermissionSetGroup – All Permission set groups created in the org.
MutingPermissionSet – Dependent on PermissionSetGroup. Needs to be used with permission set groups mentioned.

Summary

Ever since the official Salesforce Admin blog had talked about possibly removing permissions on profiles, I have been inquisitive to see how things would turn out. Permissions Set groups is one huge step forward in that direction and, if adopted properly is a powerful tool for admins.

Thanks for reading my blog post. Hope you enjoyed the content!

0 Comments

muting permission sets, permission management, permission sets, Principle of least privilege, salesforce permissions

StatusNeo