Understand the difference between roles, profiles and permission sets

  • February 21, 2022

This article will help you understand the basic difference between Salesforce roles, profiles and permission sets and when and how they should be used.

What is a profile in Salesforce?

Profiles control what users can do in your Salesforce org. This can be referred to as CRED:

  • C = create
  • R = read
  • E = edit
  • D = delete

You may want some users in your org to read and edit leads but not delete them. CRED enables you to mix and match what a specific user can do with each object.

In addition to objects, profiles also control:

Each Salesforce user in your org has a profile. Profiles are designed to group users into functions.

The most important profile in the org is ‘System Administrator.’ Users in this profile have absolute access. In addition to CRED, they’ll have ‘View all’ and ‘Modify all’ selected for each object.

They’ll also have ultimate permissions, namely ‘Modify all data’ and ‘Customize application’ that you wouldn’t want to give to any other users! (found under the ‘Administrative Permissions’ section).

What is a Salesforce role?

Roles are designed to increase data visibility and open up access to Salesforce records. You’ll have a baseline visibility set for each object in your org, known as the ‘org wide default’ (organizational-wide default, OWD). Examples of this could be:

  • Opportunities are set to ‘Private,’ which means that users can only see the opportunities they own.
  • Accounts are set to ‘Public Read/Write’ so that any user can help to update account information.

Golden rule: the ‘org wide default’ should be set to the most restrictive level. Salesforce permissions work by opening up access, not by locking them down. So, start with the strictest in mind.

There are two ways to increase data visibility via roles, essentially superseding (pushing past) the OWD:

  • The role hierarchy
  • Sharing rules

Salesforce roles and profiles

There’s some confusion when a Salesforce org is using both profiles and roles. They’re designed to be used together — it’s not an either/or decision.

It may help to think in different shapes. Profiles are like circles, whereas roles are arranged into a hierarchy (when using the role hierarchy).

Profiles are like circles of users that share the same function (Marketing, System Admin, Sales or Support). Roles are how users relate to each other in a hierarchy (the VP of Sales is above the sales managers in the role hierarchy).

Permission set vs profiles

Permission sets could be considered add-ons for profiles. They offer flexibility in how you add certain permissions (objects, field-level security, page layouts, record types, apps, tabs) to certain users — almost like you’re tagging an individual user. To grant a specific ability to a user, you don’t want to create a new profile for that one difference between their abilities and the rest of their team!

Let’s take an example

There’s a sales team who has the profile ‘Sales User.’ Only Carole should be able to change the team’s email templates, so the admin has created a permission set called ‘Modify Email Templates,’ which she’s added to Carole’s user record.

Permission sets are visible from the related list on the user’s record.

Permission sets can simply be added and removed, from ‘Available Permission Sets’ to ‘Enabled Permission Sets.’

— By Dilsha Khan