Strategy for Profiles and Permission Sets

Ensuring that your end users in your Salesforce org have the necessary and only the necessary permissions to perform their job is essential. Salesforce offers numerous different ways for admins and developers to enforce security across multiple levels:

1. Org
2. Object
3. Field
4. Record

For object- and field-level security, there are two main options: profiles and permission sets. A user is only allowed to have one profile but are allowed to have multiple permission sets. When should we use profiles and when should we use permission sets?

Limit Your Profiles

I’ve encountered a lot of Salesforce organizations, especially large orgs, which used mainly profiles and rarely permission sets. My recommendation is to limit the number of profiles in your org as much as possible. It may seem like a good idea to map each user group to a profile but that may not necessarily be the case. When you have a large number of profiles, it becomes increasingly hard to manage as your org grows.

In my opinion, there are only a handful of scenarios where you would choose creating a new profile vs a new permission set.

1. Setting page layout assignments
2. Setting login IP ranges
3. Setting login hours

“What if we need to bypass certain validation rules for a subset of users?”

It is true that we do not have the ability to reference permission sets in validation rules, formula fields, etc. But we do have the ability to reference custom permissions -- simply create a permission set that contains the custom permission and assign it to the subset of users. This is a more scalable solution especially when you don’t want to include everyone in a profile or you want to include users across different profiles.

Map Permission Sets to Job Functions

I recommend creating permission sets according to a specific function that an end user needs to be perform. Some examples:

1. View Reports and Dashboards
2. Run Reports and Dashboards
3. View All Data
4. Delete Cases

We want to create permission sets that are as reusable as much as possible. We should also try to not have permission sets overlap one another. What I mean by that is, let’s say we created a permission set for Tier 1 Support Agents and another permission set for Tier 2 Support Agents. Tier 2 support agents should have all the access that Tier 1 Support Agents have. Rather than including the tier 1 permissions in the tier 2 permission set, I recommend only having the exclusive tier 2 permissions and then assigning Tier 2 Support Agents both tier 1 and tier 2 permission sets. This becomes more clear if we’re creating permission sets according to job functions and not job role.

What if a user has to perform a large variety of functions? It could be frustrating for admins to make sure they assign all the correct permission sets each time a new user is provisioned or if their job responsibilities change.

	
  for (let i = 0; i < cars.length; i++) {
  	text += cars[i] + "
";
	}
  

Enter Permission Set Groups

In the Spring’ 20 release, Salesforce has made Permission Set Groups generally available -- which made it even more convincing for Salesforce orgs to move to a permission set-centric model rather than profile-centric model. Now we have the ability to group multiple permission sets into one permission set group and all the admin has to do is assign a user to that group for them to get all the underlying permission sets.

In conclusion,

1. Limit your number of profiles to the bare minimum
2. Create permission sets according to job functions/tasks
3. Create permission set groups according to job roles