Profiles have been around for a long time, and, until recently, they were the best way to segment users into access groupings in order to restrict access to Salesforce objects and fields. They are the traditional baseline of access control. But sometimes, it is easy to have too much of a good thing, and Salesforce orgs quickly became overly propagated with profile after profile, some going as far as a profile for every Salesforce user. Enter the newcomer Permission Sets.
Why Permission Sets?
Permission Sets are not technically new since they have been around since 2012. However, the use of Permission Sets is now being encouraged and will soon be forced as Salesforce transitions away from Profile-level, field-level access. The handling of multiple Permission Sets was difficult, so Salesforce introduced the concept of Permission Set Groups to aggregate multiple Permission Sets under one umbrella, then, soon after, Muting Permissions to restrict access for Permission Set groups. A little confusing?
How to Set up Permission Sets, Permission Set Groups, and Muting Permissions
Let’s walk through the scenario together; then, we will go into the solution.
Let’s say that your B2C sales organization has three core teams:
A role hierarchy is set up to ensure visibility to records based on each person’s position:
- Account Executives report to Sales Managers, however, this structure ensures that Customer Success has visibility into only the records that their Account Executives own, while the Sales Manager has access into all records owned by all of their Account Executives and Customer Success reps.
- Sales Managers need a sweeping view and edit access to all objects related to the customer journey.
- Customer Success is responsible for retention and upsells, so fields related to these processes should be editable.
Account Executives are solely focused on new sales, so their visibility should be limited to hone all focus on data that leads to deals.
Let’s use our imaginations and assume that this list of field and object permissions fills up a few pages. It’s not a simple set of three items!
Luckily, there’s a solution to manage access and move on from just using Profiles:
We have one Profile – Sales – that we use for these roles since the requirements for these groups are the same across three key items controlled by profile:
- Login IP ranges
- Default Record Types
- Page Layout Assignment (AND dynamic forms)
We should also expect that there will be field additions and changes to requirements over time, so the Permissions Sets need to be set up so that a future admin would understand exactly what we have in each one. Ie, A permission set for each role could technically work, but it would be harder to maintain than permissions set up by Object and then grouped.
Let’s create two permission sets:
- Accounts and Contacts – since they have similar access requirements for our team.
- Assets – Accounting also needs to update this data, but this team does not edit Accounts or Contacts. Thus, we will keep it separate to make our Permission Set reusable!
We also need three Permissions Set Groups – one for each role. These groups will aggregate our two permissions sets and allow us to add muting permissions to restrict access per role.
Back to our Permission Sets:
- Accounts and Contacts:
- Rating Field (Account): Read/Edit
- Warranty Expiration Field (Contact): Read/Edit
- Asset: Read/Edit all fields
At the time that this article was written, read and edit access to all fields on an object is a.. pain in the **insert emoji of Donkey from Shrek**, but there is hope! Follow the progress of “Select All” here.
Permission Set Groups & Muting
There are three Permission Set Groups for each of our core user groups:
Our Sales Manager group is the easiest one to create – we just assign the two permission sets, and we are good to go. Why? This position has the widest data access level out of the three. All our permission sets are designed for the widest level of access -then access is limited via muting permission sets.
For this position, we apply both of our permissions sets and then apply Muting Permissions to limit access to the Warranty Expiration filed on Contact and the Asset object. Unlike Permission Sets, we create Muting Permissions directly from the Permission Set Group – not the Permission Sets page.
A muted permission in a permission set group restricts access to the field, object, or feature regardless of what the permission sets assigned to the group grant:
We simply mute edit access to the field and mute edit access to all Asset records – then we can reuse the same permission sets for the Customer Success position.
Again, another Permission Set Group, the same two permission sets, then muting permissions.
How do I transition from Profiles to Permission Sets?
Salesforce has a Profile -> Permission Set conversion tool, which may work for some smaller Salesforces. Those that are larger, need to watch limits, as there are only 1,000 permission sets allowed for most implementations.
Trailhead’s Data Categorization and Access Superbadge is a great starting point.
CapStorm Helps You Transition to Permissions
Permissions transitions can be a tricky thing to master. It’s often tough to ensure that you do not accidentally impact a user’s day-to-day job by removing access to something that you did not know that they used in the first place!
A good plan is to minimize risk by backing up metadata frequently. Backups with CapStorm automatically version meta changes so that you can, in just a few clicks, roll back to the original profile, if needed, or fix a permission set.
Ready to learn more? We’re here to answer your questions!