Salesforce 101: Roles vs Profiles


Salesforce 101: Roles vs Profiles

  • kyle
  • 30 Jan 2019

TLDR; Roles determine your position within the hierarchy and profiles determine what data you can see

It seems like almost every day we get a question from a client asking: "Can you set person X's role to System Administrator so they can see everything?"

Not only does that sentence not make sense(roles and profiles are different) it underscores how confusing Salesforce is for non-technical users.

Let's start with some basic definitions:

User Role Hierarchy(Roles): 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. See More Here

Profile: Profiles define how users access objects and data, and what they can do within the application. See More Here

The way to keep these things straight is to first know that Profiles are required, but Roles are not. Profiles determine which objects, fields, etc. you can access where roles determine what you can see relative to others in the hierarchy within the organization, for example - your boss can see each of his/her forecasts, but you can only see yours and not your colleagues. Typically, you'll set a user's profile to something like Sales or HR or System Administrator. This will determine what access they have within the system. Can the user view the setup screen? Can they create/edit apex or sandboxes? Can a user modify change sets or create users? Can the user view/edit/delete a given object? All of those questions are answered by the profile the user is assigned to.

Roles on the other hand show where you stand relative to other users within the organization. Any records I can view/edit should roll up to my manager so they can access and ultimately the VP of X, CEO, etc.

What creates confusion is that there are four ways of deciding what records a user can see:

- Org wide sharing defaults

- Profiles

- Permission Sets

- Roles

Org-wide sharing defaults are just that: Organization-wide sharing defaults set the baseline access for your records.

If your org-wide defaults are public view/edit then every single user in the organization will be able to view and edit a given record. Sometimes that makes sense, sometimes it doesn't. But if you set that to view/edit then every user will be able to view. Let's assume you're diligent and all objects are set to Private. Next comes profiles.

Let's break this down a bit further

Scenario 1: Private Org-Wide Default on Opportunities; No Access on your Profile to Opportunities;

- You will not be able to see, create, edit or delete any opportunities in Salesforce

Scenario 2: Private Org-Wide Default on Opportunities; Create/Edit on your Profile to Opportunities;

- You will be able to see and create opportunities yourself but will not be able to view/edit anyone else's opportunities

Scenario 3: Private Org-Wide Default on Opportunities; Modify All on your Profile to Opportunities;

- You will be able to see/edit/create anyone's opportunity

Scenario 4: Public Read Only Org-Wide Default on Opportunities; Create/Edit on your Profile to Opportunities;

- You will be able to see all opportunities and will be able to create/edit your own

Setting your Org-wide defaults to private is not the standard approach small to medium sized business take due to the added complexities of users now not be able to see data. This prohibits transparency across the org when it is not necessarily needed amongst employees. As companies get larger and want to be more compliant and protect their data, it becomes increasingly more important to consider your organization-wide defaults and set parameters around what users can see or do within their org.

Permission sets defined

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.

This means that permission sets are almost identical to a Profile but you can assign them to specific users. Let's say you want two users to have API access but they're a part of a profile that the entire Sales org is using. In that case, you'd create a permission set and assign it to those specific users. That way, your restrictions stay in place for everyone but the assigned users.

Permission sets will only expand functionality, never restrict functionality. Only applicable for when you're trying to open access for users to do or see something.

Now enter roles.

Let's say you have Private access on Org-wide defaults, No visibility in your profile to a given record, no permission sets assigned but someone lower than you in the role hierarchy can view/edit a given object, what then?

In that situation you, as their manager, will have access to that object. It would make sense that if I'm the CEO of a company, I should be able to see/edit anything my subordinate is working on and same for my subordinate to their subordinates.

To be frank, Roles are not as commonly managed among our typical customers nearly as much as Profiles. They tend to be an afterthought, mostly because companies we work with don't always use forecasting and rarely close down view access to records with Org-Wide sharing defaults.

There is one big caveat to understanding Roles. Earlier, I mentioned that if you are above someone in the role hierarchy you can automatically see records they can see. That's generally true because SFDC sets object access to Grant Access Using Hierarchies and for standard objects you cannot change that customization. You can, however change that setting for custom objects. So, in short, if you are above a user in the role hierarchy you will be able to view all their records unless there's a custom object your admin specifically set to to be visible which we really haven't seen before. See More Here