Salesforce Best Practices: Where Permission Sets Shine

A few months ago, I read a blog on permission sets and how another consulting company (Arkus) had managed to do an implementation with just two profiles. That same company has now created a tool called The Permissioner to mass assign users a permission set, which I think is a great help to system administrators who, like Arkus, are planning to heavily use permission sets.

I think Arkus has an interesting approach, and I agree that permission sets do limit (to a certain degree) the number of profiles you need.  However, I still find that profiles remain at the core of the Salesforce application and cannot imagine doing an implementation for one of our customers with only two profiles. Profiles are extremely robust and allow you to control many features that permission sets do not control. You set access to Tabs, Apps, and record types at the profile level, not on permission sets. Page layout assignments are done at the profile level. In reality, the profile should be at the core of what you are doing.  Then from there you can use permission sets to extend special permissions to users.

The Manufacturer’s Guide to Marketing Through Partner Enablement in 2021

Learn how partnerships allow manufacturers to scale revenue growth beyond what’s possible with direct sales alone.

Get the Guide

Where you really have to struggle with permission sets is when you try to use them to add full access to an object and take profiles out of the equation.  Adding CRUD permissions is easy through a permission set, but controlling full field-level security is more difficult. For example, imagine you were building out a new application and wanted only a few of your standard users to use the application.  The approach is not to create a permission set that gives full access to the objects and fields.  Instead, you’d want to control field-level security through the profile and CRUD permissions through a permission set that you would assign to users who will need to use the application. Why? If you try to control field-level security exclusively through a permission set, there are a lot of clicks involved (all fields are unselected by default and you have to manually click each and every field to add them to the permission set).

In addition, down the line, when you add a new field to an object, the application doesn’t allow you to select visibility for permission sets.  This is because you should be managing field-level security primarily off of profiles, and you would have to go find all permission sets affected by this new field and add visibility there. Always make the primary place you control field-level security on the profile, and if all users don’t need access to the object, grant access to it by permission sets. If you need to add more visibility or the ability to edit certain fields, add only those fields to the permission set.

I recently completed a project where we wanted to extend the Manage Public List Views permissions to a small set of users as well as delete permissions to a certain set of objects for managers of the application. Since page layouts, record types, and tab and application access were the same for managers and their direct reports, rather than creating a new profile we made a very simple permission set to manage list views permissions and delete permissions to several key objects. If there is a field that only managers should be able to access, make it read-only for the profile and give read-edit permissions to managers through the permission set rather than controlling editing through the page layout itself (which would mandate two page layouts). This is a great use of permission sets and a clear illustration of where they really shine.