Understanding Roles, Profiles and Permission Sets in Salesforce

Access management is arguably one of the most important components of front-line Salesforce security — but there's a lot more to it than just password policies. We covered the Salesforce Security Health Check in a previous post, but if you want to get about managing access, you need to understand roles, profiles and permission sets. Without proper visibility into how these controls work — and how they affect what users can see and do on the platform —  you could be vulnerable to any number of security and compliance risks.

What's the Difference Between Profiles, Permission Sets and Roles?

In Salesforce, profiles and permission sets define what a user can do. Roles, on the other hand, define what they can see. Watch this explainer clip for a quick overview of Salesforce access from our webinar on the topic:


Before we move on, let's unpack this a little bit. 

Profiles and permission sets both control CRED (Create, Read, Edit, Delete) permissions on Objects, fields, user settings, tab settings, app settings, Apex class access, Visualforce page access, page layouts, record types, login hours and login IP ranges. Every user must be assigned a profile when they’re created on the platform — and there can only be one profile per user. Essentially, a user's profile is the baseline authorization of access to the Org. 

Permission sets are, as the name implies, a set of additional CRED permissions that can be applied to different profiles. Typically they are task-based and related to different Objects and managed packages. For example, Sales users may be assigned a permission set giving them access to a CPQ app to generate quotes. 

Users may be assigned multiple permission sets — or none at all, making them a far more dynamic and flexible permissioning model than profiles. They were introduced with the intention being mixed and matched, and given to different users depending on job role. Imagine a house — permission sets are the keys for different rooms that are given to a single guest. 

Last, but certainly not least, are Salesforce roles. Roles and sharing settings control what a user can see, by governing access to records and folders. Unlike profiles, roles are hierarchical based on the level of data access required. For example, a CEO or department head will likely need to see more than an associate-level employee, for obvious reasons.

The main benefit to building a hierarchical role structure is that it allows for scalability as your organization grows. With tiered access to specific sensitive data, it's easy to add more staff, or promote internally, while still maintaining tight controls around who can see what.  

The Problem with Salesforce Profiles 

While profiles are the baseline for user access, they can get fairly complex. As we mentioned above, users can only be assigned exactly one profile — but as job responsibilities change over time, profiles are often cloned and edited to reflect an organization's evolving access needs. 

The result is that, in a mature Org, profiles are too often driven by employee needs rather than a regimented security design. It is not uncommon for users to have old permissions on their profile that they no longer need — and as staff move in and out of roles, old profiles may be left unused, creating an unmanageable amount of clean up work and the potential for unauthorized access that can be an inherent security risk. 

Moving from Profiles to Permission Sets

So, how do you manage the problem of 'profile chaos'? Our recommended best practice — and Salesforce's, too — is to keep profiles as simple and restrictive as possible, and use permission sets to manage the nuances of access for different job functions. Getting there from a state of profile chaos is a four-step process:

  1. Determine what each profile in your system does
  2. Compare profiles and extract the differences between them
  3. Group these differences into permission sets
  4. Consolidate profiles and deactivate anything redundant

This can be a difficult project, especially in a longstanding Org with a lot of profiles. Fortunately, there are some free tools available that can help automate things. Learn more about them here.  

Principle of Least Privilege

The principle of least privilege is the one of the best ways to maintain Org security — it's founded on the notion of giving individuals only the minimum access privileges necessary to perform a specific job or task and nothing more. Limiting the number of privileged users is one of the five best practices recommended by the National Cybersecurity and Communications Integration Center (NCCIC) at the U.S. Computer Emergency Readiness Team (US-CERT) as part of every organization’s cybersecurity strategy. 

The good news is that, once you've cleaned up your profiles and migrated to using permission sets, maintaining the principle of least privilege is a lot easier. GearSet suggests using a 'minimum access' profile for almost all non-admin users. 

Using Strongpoint for Better Visibility

Strongpoint automatically documents and monitors your access controls — and gives you tools to map out connections between roles, profiles, permission sets, Objects and fields. With it, you can investigate who has access to critical Objects and fields, run cleanup projects and track changes to user access on an ongoing basis. 

Looking for more tips on keeping your Org secure? Download our eBook, Salesforce Access Controls: Best Practices for Managing Risk, or reach out to sales@strongpoint.io today.