logo

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. 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.

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 permission 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.

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 Netwrix Strongpoint for Better Visibility

Netwrix 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. 

As VP of Sales and Marketing, Paul is responsible for driving growth of of the Infrastructure and Applications products in the Netwrix portfolio. His main areas of focus are security and compliance for NetSuite, Salesforce and Network Infrastructure. He is passionate about Go To Market Strategies and driving positive outcomes for customers. Previously, Paul served as the VP of Sales and Marketing at Strongpoint where he ran Go To Market functions before it was acquired by Netwrix. Paul holds a Bachelor of Arts degree and a Masters in Business Administration from McMaster University in Hamilton, Ontario, Canada.