Permission Sets: The Elegant Solution to Preventing Permissions Chaos

When I joined Technology & Product at Salesforce over eight years ago, my mission was simple – make the world of profiles for admins easier. But, becoming the product manager in charge of profiles and user permissions was analogous to taking the red pill from the matrix (listen to my interview on #ButtonClickAdmin podcast to hear the full history!).

Improving Admin User Experience

When I started, the profile page had grown so unmanageable that I would bring a four story tall roll of paper to Dreamforce to highlight how long, and unusable, the page had become. 

From this experience, we built the enhanced profile user interface and kept the length of any particular permission page to the height of a table top. And, in combination with the enhanced list views for profiles, we started to introduce some level of management into permissions by mass editing up to 200 profiles worth of user and object permissions.

The Least Privilege Concept

Ultimately, getting the ‘profile house’ in order was a matter of introducing least privilege into an Admin’s life.

Least privilege is a simple concept: users should have the least number of permissions necessary to do their job and nothing more. To accomplish this, we needed to break up the singleton that is a profile. But this wasn’t as easy as just assigning multiple profiles to a user.

Profiles were built with specific design constraints in mind:

1. Every user has to have one and only one profile that represents the totality of what they can do in the app
2. Every profile is an instance of a license. As a result, it was possible to have a proliferation of profiles that functionally did the same thing, each one tied to a different user license
3. Profiles are never created, they are cloned. As a result, they always have baggage. In order to create a profile with no permissions, you first have to clone it and then remove all the permissions before you have an empty container to work with.
4. Because profiles are cloned, there was never such a thing as ‘this profile has only one more permission than that one.’ Cloned profiles were rarely a superset of another profile – they were more typically something completely new and revolutionary.
5. Profiles are in a very limited 100% club. 100% adoption that is since every user of the service has to have one. As a result, any changes that were introduced had to be done in such a way that it didn’t explode any minds working with them (since they depended on them) or bring the service to its knees.

The Answer is Permission Sets

The easiest way to describe the effort to create permission sets was that it was like changing a propeller into a jet engine while the plane was in flight. To move everyone to a least-privilege model meant we had to roll it out very carefully. And at one point, after we were 99% of the way there, the entire project almost was scrapped due to fear that it would bring the entire service down!! Luckily, cooler heads prevailed.

But for admins, this meant they could start assigning discrete additional permissions to their users aligned to an app, a region, a line of business, or really any other arbitrary business grouping. In talking about comparing profiles and permission sets(3), I ran some simple numbers for a basic org and found that even simple profiles could have thousands of different permissions possible with an infinite number of permission permutations!

Permission sets simplified this problem by reducing the number of permissions you needed in a profile by offloading them to discrete permission sets. Now admins could reduce the overall number of profiles in their org by assigning fewer permissions to a broader group of users and focus on specialization with permission sets.

And, to reduce some of the challenges with licenses, we introduced license-less permission sets which allow you to configure simple permission sets that span license allowances by not choosing a license when the permission set is created. Then at assignment time, we would validate that we don’t invalidate any licenses tied to the permission set assignees and we were off to the races reducing permission set proliferation.

Admins now have more flexibility in creating, assigning, and managing user permissions.

Further resources from the Salesforce Hacker Blog

Permissions is a complex topic and not necessarily easy to grasp. Throughout my journey of improving the admin experience, I created a repository for best practices, tips, and tricks related to salesforce admins working with profiles and permissions that should answer all your questions!

Here are some popular posts:

1. How to remove unused profiles using reports
2. Modify All Data (nicknamed the death star permission for being the ultimate power in the salesforce universe)
3. Comparing Profiles and Permission Sets

Using the API to extend what an Admin’s user experience:

4. API First for Administrators
5. Permissioner
6. PermComparator [It enabled enterprise IT to focus on access control integrations]
7. Permission Set Best Practices