Salesforce Permission Sets All Grown Up

Now that it is three years later I want to officially state that they are all grown up and a first class consideration on the Salesforce platform. Here’s a little walk down memory lane to talk about where they started and how far they have come over the years.

Origin Story

Salesforce Permission Sets were first generally made available in the Winter 12 release of Salesforce. Since then they have evolved to become a very integral part of the permissions scheme within the platform. I had the privilege of talking with the product manager in the run up to permission sets becoming a feature and provided many use cases around managing a large Salesforce instance and how it was becoming increasingly difficult to manage all 3,000 of my users’ permissions. We were truly using Salesforce as a platform and with so many applications it was very hard not to fall into the trap of “profile proliferation” just because a handful of users needed one or two additional system permissions or read access to certain object that nobody else needed.

Initially permission sets solved this problem really well by providing a mechanism for applying permissions as an addition to a profile on a user by user basis. Over the years though they have evolved into a full platform feature by which entire functionality is either on or off for users. It has become the de facto way to turn on specific applications, enable users with licenses to add on applications, and generally the first thing I think about when rolling out new functionality and designing permissions within a Salesforce project.

Ideas Delivered Over the Years

• Record Type Selection in Permission Sets 
• Permission Sets - Tabs permissions please
• Mass add existing Users to Permission Sets - 
  • Though we are partial to using The Permissioner instead

API First, Permission Set First

Permission sets were always designed with an API first mindset. This allowed for certain features to be available on the platform but without a user interface. To me this means the feature has always been extremely robust and allowed ISV partners of Salesforce to build specialized admin tools and integrations utilizing permission sets, case in point: The Permissioner. A lot of ISV partners have made it a common practice to package permission sets with their applications as a way to grant access to their functionality post installation from the AppExchange. This is really a new way of thinking about delivering applications. No longer does an admin have to go in and edit every profile in order to provide access to applications, rather they can simply assign the appropriate permission set to their users. Salesforce has even followed suit here and has provided the ability to assign things like 2-factor authentication or Sales Console assignment via permission set or permission set license assignment.

All in all permission sets have grown so much over the last three years and have really become at the forefront of permission design. In every release when reading the release notes I love seeing that a new feature when announced can either be turned on by changing profiles or can be assigned via a permission set. The fact that Salesforce encourages admins to create permission sets to provide new functionality is a testament to how great permission sets are and how far they have come.

Please feel free to comment below, on the Salesforce Success Community, on our Facebook page, or directly at me on Twitter @JustEdelstein.