One of the tenets of Salesforce has always been the emphasis on trust and security for its solutions. However, consultants have often complained that getting the right permissions to the right people was not an easy task. Slowly but surely, however, Salesforce has been adding features to make life easier. The latest in this list are Muting Permissions and Restriction Rules. These permissions have been much clamored for, and will allow administrators to remove permissions that had been otherwise granted. I can’t stress enough how huge a shift this is, since until now you couldn’t remove something once it had been given.

What are they?

Much like we have with Profiles/Permission Sets and Sharing Rules, Muting Permissions and Restriction Rules are tools that apply to the objects and the records themselves, respectively. With Muting Permissions you can remove access to functionality and objects that Permission Sets granted, whereas Restriction Rules tighten access to data after OWD, Role Hierarchy, Sharing Rules or Manual Sharing have opened those up.

In the following two sections we’ll show you how to use each of these tools to maximize your solution.

Muting Permissions

Implementation

The first thing you need to know about muting permissions is that they are only available within Permission Set Groups. This may seem like a bit of an unnecessary complication but it’s actually quite the opposite. 

You may know by now that profiles are getting progressively less important and permission sets are the way of the future. You also know that with Permissions Set Groups you can now create very granular Permission Sets, then put them together in various combinations to create powerful ways to give your users what they need, without creating unmaintainable behemoths. For ISVs, it also means that they should shift towards very granular, feature-specific Permission Sets, to give subscriber administrators more flexibility when giving their users access to installed applications.

In that sense, the idea is that you would put a Permission Set Group together and then say “remove THIS”. So, if you had two groups that needed almost identical permissions except for one tiny little thing, now you no longer have to create a brand new Permission Set — you just create a new group and then you remove that tiny little thing! How easy was that?

Keep in mind, however, you’re allowed only one Muting Permission per group, and that Muting Permission is specific to the group in question. For most this is not a problem, but it does mean that you cannot re-use that Muting Permission. On the plus side, you can mute as many things as you want there.

My advice is to add all the Permission Sets first. Then the platform will calculate the additive permissions and you’ll have a much easier time figuring out what to mute.

How to leverage your Managed Packages

Muting Permissions really shine when you combine them with Managed Packages. Let’s face it, ISVs like to make frequent updates available to their clients. Your company, however, may not always be able to adopt all the new features immediately. Or perhaps the permissions that a package grants are just a bit too open. In the past, what admins did was to clone these Permission Sets, and then remove the offending access. While that worked, it left those cloned Permission Sets forever out of sync with the package and therefore Admins needed to constantly update them to stay current with new features being released.

With Muting Permission Sets, you can very easily create a Group, add your own Permission Sets along with Permission Sets from the Managed Package and then remove everything you don’t want to give your users. As a big bonus, the Managed Permission Sets keep getting upgraded, so functionality is a lot less likely to break when updates are made.

So, the next time your favorite ISV releases a feature that you are not ready to adopt or you install a package that gives permissions you don’t think your users should have, you know what to do!

Gotchas

There are always some things to be on the lookout for when Salesforce releases new functionality and this feature is no exception. First thing is that Salesforce will compute the dependencies of the permissions you mute and it’ll mute them for you. For example, if you mute “Run Reports”, every permission that depends on it will be muted as well. There is a screen warning you first, but it’s easy to just click “ok” if you’re not paying close attention to what you’re doing.

While Muting Permissions are retrievable and deployable (the Metadata Type is named MutingPermissionSet and these records are referenced in the PermissionSet Metadata Types), as of Winter ‘22 you may not include them in Classic (1GP) or Managed (2GP) packaging. They are, however, available to be distributed via Unlocked (2GP) packaging. This makes sense for now, as one of the main targets of this feature is to better control what packages actually do and, let’s be honest, if an ISV wanted to mute a permission then they simply wouldn’t include them in the package to begin with.

Restriction Rules

Implementation

You can use Restriction Rules for a variety of different things, and they can be a powerful way to keep things separated. For example, you can choose to restrict some of your users to a single Record Type, or prevent users from accessing records in child objects (like Tasks) that they normally would have access to.

Restrictions Rules will be applied after all other types of sharing (OWD, Role, Sharing Rules, Manual) have been computed, but will not work in System Mode or for users with View All/Modify All. If you’re building an ISV package, or running Apex without checking for CRUD/FLS, this could be a problem for you, so make sure to check your sharing settings to ensure you’re not bypassing them.

To create a Restriction Rule you basically need to establish four things: The targetEntity (the object to filter); the recordFilter (what can the user see?); the userCriteria (who does this apply to?); and whether the enforcementType will be Restrict (stops users from accessing the records at all) or Scoping (hides records from view but maintains access).

Custom Objects accept both types of rules but, as far as standard objects go, Restrict can only be applied to 5 objects (Contract, Event, Task, TimeSheet, TimeSheetEntry) and Scoping to 7 (Account, Case, Contact, Event, Lead, Opportunity, Task).

Gotchas

There are some known limitations to this feature as well. I will list here some of the most important ones, but if you are going to leverage this feature you should spend some time getting familiar with all of them here.

First you should know this: As of Winter ‘22, the only way to create Scoping Rules is by using the Tooling or Metadata APIs. While it is very likely that Salesforce will eventually create a GUI way to do this (Safe Harbor), it doesn’t yet exist.

You should be very deliberate with these rules, since you only can create up to two restriction rules per object in Enterprise and Developer Editions. This limit goes up to five in Performance and Unlimited. Along these lines, you need to make sure that for a given user, only one userCriteria per object matches. Meaning you can’t have any overlap in users between multiple Restriction Rules.

Additionally, you can’t leverage formula fields in your RecordFilter and the only operator supported is EQUALS (e.g: Leads.VIP__c = true is ok, but Account.NumberOfEmployees < 100 is not). Also, you can go up to only one level in your hierarchy. This means that Owner.Name is ok, but Account.Parent.Name is not.

Lastly, when you restrict an object, you are not automatically restricting its child objects. So, if you restrict Contacts, users will still be able to see Tasks or Notes for those contacts they can’t see.

Keep in mind that Scoping Rules are still in beta (again, as of Winter ‘22), so you should not include them in your managed packages or production environments yet (Restriction Rules are GA). For ISVs, it is also worth noting that this feature is not yet available for Managed 2GP packaging, though it is available for both Unlocked packaging and both types of 1GP packages (Managed and Unmanaged)

Summary

Salesforce is revamping permissions with new ways of managing access, now including the revocation of permissions. This gives ISVs and their subscribers powerful new security tools. It’s important to keep in mind how subscribers may use them and leverage those strategies both during the architecture of the solution and the post installation experience.

Muting Permission Sets are a really great tool for Admins. Not only do they make creating reusable, maintainable, and scalable Permission Sets a cinch, but they also allow them to control what Installed Packages let their users do. With Muting Permissions Sets, the installation and management of Managed Packages is now a much easier proposition, since the Administrator can now restrict what the packaged permissions do without having to clone the PermissionSets that are provided by the ISV.

Restriction Rules are a promising start, but due to the aforementioned limitations and the general newness of the feature we don’t recommend immediate adoption. Since they aren’t yet supported for 2GP, ISVs should wait a version or two before packaging rules into a product for now, but they (and OEMs) should definitely consider advising subscribers who need them on how to leverage them to solve their access issues.


Companies build their Salesforce businesses better with CodeScience. It is our mission that no ISV navigates Salesforce alone. If you’re looking for guidance on your product, help supporting your customers, or just need to ask an expert, get in touch today!