Salesforce says it clearly for quite a while and at the same time doesn’t fully allow us to do it – migrate from Profiles to Permission Sets.
In Spring ’20 they made the Permission Set Groups generally available and we are able to play with new ways how to setup permissions in our instances.
The biggest difference between Profiles and Permission Sets – as you know for sure – is that each user has to have one profile and can have one or more permission sets. The rights get extend with every new privilege, you cannot remove it if some other profile/perm set allows it.
The problem was, that at some instances there were a lot of permission sets and admins weren’t really sure, which they should assign to users and forget some of them – Permission Set Groups to their rescue. And when Salesforce was at it they also created a way we can mute certain permissions to maybe simplify our permission sets model.
The muting part catch my attention, so I did some testing to see, what I need to change when implementing it.
Migrate Profiles to Permission Sets
It is probably obvious but you don’t really believe it at the beginning. We (I) were so used to the coexistence of profiles and permission sets that it really didn’t matter where I set things as long as it fulfilled the request and don’t over extend the rights.
Sadly, the muting permission sets can only mute things set by permission sets in the Permission Set Group. So if you profile says that person has right to delete accounts and edit their web field, there is nothing you can do about it. You need to create a permission set, migrate these permission into it, assign it to all people with that profile and finally remove it from profile.
The same goes for record types – if you want some record types mute for users you need to set them in permission set.
Or if you assign permission set with these rights directly to user (and not via group) you cannot do anything about it. Remove permission sets from users, assign them to permission set group, which is assigned to users.
How to set it
It is super easy at the end. There is a new section in Setup, where you can create a new Permission Set Group.
It is super simple inside, basically just two sections on top and super important part in the bottom.
At the top you link your existing Permission Sets, which should be included in this group. You can also add (and create) muting permission sets, which are visible only here and you cannot see them between other Permission Sets.
The bottom section is as important as the top one. Here you can see the result, can quickly check any object or anything and see what it will mean for the user, which permission they will really have.
The muting permission set looks about the same as standard permission set, it just have some extra columns everywhere.
For example on object settings you cannot edit the „Enabled“ columns (including Read and Edit access) as they are inherited from the permission sets you included in the group as well. But you can edit the „Muted“ columns and mute things you don’t like.
At the end you assign the group to users the same way you would do with Permission Sets and it is visible on the user in the same way.
Continuous Integration?
You might be one of those who use repository and their source of truth isn’t in the instance. You have all your Profiles and Permission Sets there and you really like that you can download your PermissionSetGroup records as well. Sadly the MutingPermissionSet metadata aren’t supported by Salesforce DX at the moment (version 7.56.1), but it will be available soon (hopefully).
How universal is it?
I started this whole quest because of one client, who had a problem with Enhanced Notes editing. For some unknown reason inside Salesforce, only the author of the note (and those with Modify All Data) can edit it, because „you can only give others viewer access, because Notes does not support simultaneous editing. If multiple people edit a note at the same time, they overwrite each other’s content.“ Yeah, there is an idea for it.
At the time of tests for some reason the Modify All Data assigned through permission sets didn’t work, according to support it works as designed.
But when you grant the same permission on Permission set, as per permission sets functionality it grants extended access to the users who do not has access to specific functionality, this permission is not object specific and is not related to any specific functionality due to which all the basic permissions are taking into consideration for profile. For more details you can check https://developer.salesforce.com/forums/?id=9060G000000MPePQAW
I didn’t really get the explanation but it doesn’t matter as now it works as expected – you assign Modify All Data in permission set and you can then mute for example Delete right for one object. Magic, but exactly the one I like.
Will I migrate?
Well, it is tempting, but at the same time for most of my clients I’m more than happy with profiles, they are also supported everywhere (page layouts, Lightning Page assignments and such things) so I don’t feel that migration to permission sets would be beneficial.