Profiles vs Permission Sets

Do not confuse Profiles and Permission Sets with Roles

The profiles and permission sets are configuration items in Salesforce that will allow us to control different types of functionalities and the roles with allow us to control record visibility primarily.

• Role: “Salesforce offers a user role hierarchy that you can use with sharing settings to determine the levels of access that users have to your Salesforce org’s data. Roles within the hierarchy affect access to key components such as records and reports” (Help-User Role Hierarchy).
• Profile: “Profiles define how users access objects and data, and what they can do within the application. When you create users, you assign a profile to each one” (Help-Profiles).
• Permission Set: “A permission set is a collection of settings and permissions that give users access to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles” (Help-Permission Set).

From the object (records) point of view, the objectives of each one can be confused.

There are other considerations to take into account to understand the differences between them:

• The user can have only one Role (optional, but strongly recommended).
• The user must have one Profile (required).
• The user can have several Permission Sets assigned (optional).

What functionalities are controlled by Profiles and Permission Sets?

The following image shows that the functionalities controlled by a Permission Set are a subset of those controlled by a Profile. But that doesn’t mean that a Permission Set is a subset of a Profile.

We can set almost everything with a checkbox value, except for Login Hours, Login IP Range and Page Layout Assignment.

Understanding the checkboxes values in Profiles and Permission Sets

The system will first apply the user’s Profile permissions and settings and after that, if there is a link between the user and one Permission Set, the system applies the Permission Set permissions and settings.

The Profiles have the potential to allow or deny the permissions of the user, but the Permission Sets are only able to enable permission that was denied by a Profile. In both, Profiles and Permission Sets, there are several checkbox settings like Enabled, Read, Edit, etc. For each checkbox value combination, the following table shows the implication of a Profile setting and the effect of the Permission Set.

Profile	Permission Set	Permission Set Effect
CHECKED (the user has the permission granted)	CHECKED	Doesn’t have any effect, the Profile already set the permission.
CHECKED (the user has the permission granted)	UN-CHECKED	Doesn’t have any effect, the Profile already set the permission.
UN-CHECKED (the user doesn’t have the permission granted)	CHECKED	The user has the permission granted.
UN-CHECKED (the user doesn’t have the permission granted)	UN-CHECKED	Doesn’t have any effect, the Profile already set the permission.

We can see that the Permission Set is useful only when a Profile denies permission to a user in a particular object or configuration item.

For Tab Visibility (that does not use checkboxes as settings), the logic is the same.

From a strict point of view of CRED (Create, Read, Edit, Delete) properties on objects and fields, the following image shows the differences between Profiles and Permission Sets.

Profiles vs. Permission Sets: best practices

The following are recommendations related to Profiles and Permission Sets:

1. Keep the numbers low: try to use the minimum number of Profiles possible, and to grant more permissions to some users, create a Permission Set. But keep in mind that a low number of Permission Sets is good too.
2. Functional orientation: the Profiles are tightly related to the Role or job that the user does in the company. And so, they are functionally oriented by default. Create the Permission Sets in the same way, for instance, having a Permission Set “Transfer and Delete Accounts” is better than one named “Marketing Manager P.S.”.
3. Deny when possible: try to be as restrictive as possible with the permissions granted by a Profile. It is better to have one Profile “Sales Profile” than “Sales Rep Profile” and other named “Sales Manager Profile.” Any extra permission that the sales manager needs; can be granted through a Permission Set. For instance, if in the company, the sales manager will be allowed to delete Accounts and not the sales representatives, then we create one Profile (Sales Profile) that does not allow to delete Accounts, and we assign it to all the sales users. We then create a Permission Set (Delete Accounts P.S.) assigned to the sales manager only; that will grant the Delete Account permission. Following this practice will allow you to keep the number of Profiles low.
4. Modular and Reusable: if you think about your Permission Sets as modular sets of extra permissions, where you will grant as many permissions as needed; you will be able to reuse them. For instance, if you followed point 3 above, the Permission Set in the example can be assigned to the sales manager and to the marketing manager too (if needed). Following this practice will allow you to keep the number of Permission Sets low.

Wrap Up

The Profiles are the core configuration item when you want to grant permissions to many functionalities in Salesforce. They have been there for a while, but because the administrator user ends up creating many profiles, one for each user and particular needs, Salesforce created the Permission Sets to avoid the situation. The Permission Sets are Profiles complement that adds permissions but not revoke them.