This post was last updated on 3/29/21.
Overview
It seems like almost every day we get a question from a client along the lines of, “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 administration can be 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, along with sharing settings, to determine what levels of access users have to your Salesforce org’s data. Learn more here.
Profile: Profiles define how users access objects and data and what they can do within the application. Learn more here.
Profiles, roles, and other sharing methods
Profiles are required, but roles are not. Profiles determine which objects, fields, etc. a user can access, and roles determine what records a user can see relative to others in the organization’s hierarchy.
Typically, a user’s profile is set to something such as Sales or HR or System Administrator. This will determine what they have access to 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? The answers to those questions is determined by the profile the user is assigned to.
Roles, on the other hand, show where you stand relative to other users within the organization. For example, your boss, who is likely positioned higher in the role hierarchy than you are, might have the permission see their own forecast records as well as yours, but you can only see your own records (and of course, records of users below you in the role hierarchy).
This seems straightforward enough, but confusion still rears its head because there are several factors additional that influence which records a user has access to, such as:
- Org-wide sharing defaults
- Role hierarchy
- Sharing rules
- Manual sharing
- Profiles and permission sets *
These factors operate like a funnel, providing different levels of record access. See the chart below to understand what we mean:
*Profiles and permission sets aren’t included in this chart. This is because the sharing methods only come into play if the user has access to that object either through their profile or a permission set. If a user has no access to an object, the sharing methods will not affect them as they are unable to see records from that object no matter what. For more information on profiles and permission sets, scroll to the next section.
- Org-wide defaults are the most restrictive levels of access. When set to public read/write sharing, users have complete freedom to all records of the object for all users. Private sharing, though, restricts access to any records of the object unless the user explicitly owns the records. Note that that other sharing methods in the funnel come into play only if the Org Wide Default is not set to public read/write.
- The role hierarchy is a defined structure of how records should be shared within your Salesforce org (it might match your company’s organization chart). Users higher up in the hierarchy will have complete access to records owned by them and their subordinates, but no access to records owned by users higher in the hierarchy (unless sharing methods from higher up in the funnel are used).
- Sharing rules act as a bypass of org-wide defaults and the role hierarchy. They offer ways to share records when certain users, roles, territories, or public groups still need access to records despite the org-wide defaults and role hierarchy configuration.
- Manual sharing is a way to share one specific record with another user who otherwise would not have access due to the org-wide default or their particular role. Note that, in some cases, manually sharing a record will also share its related records.
Profiles and Permission Sets
Profiles and permission sets are collections 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 part of a profile that the entire sales department is using. In that case, you could create a permission set and assign it to those specific users. That way, the API access restrictions stay in place for everyone except these two assigned users.
Permission sets will only expand functionality. They never restrict it. Therefore, they’re only applicable for when need to open access in order for users to do or see something.
When it comes to record access, the main thing to remember is that a user can only see records if they have either profile or permission set access to the object that those records belong to.
More on Organization-Wide Defaults
Org-wide sharing defaults exactly what they sound like. They set the baseline access level for your records.
If your org-wide defaults are public read/write, then every single user in the organization will be able to view and edit a given record. Public read/write removes the need for any of the other sharing methods, because everyone is already allowed to see and edit the records. Sometimes that makes sense, sometimes it doesn’t. You know your company best.
Here’s a chart illustrating some scenarios with different org-wide defaults and profile access options.
More on the Role Hierarchy
The role hierarchy allows you to create an “otherwise-set-in-stone” structure of record access. This means that if a sharing rule or manual sharing is configured, that lets the users see the records, but otherwise, record access is based on this role hierarchy.
In our experience as Salesforce consultants, roles are not as commonly managed as profiles. They tend to be an afterthought, mostly because a lot of companies don’t use forecasting, and so they rarely close down view access to records with org-wide sharing defaults.
We mentioned earlier that when you are above someone in the role hierarchy, you can automatically see the 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, if you are above a user in the role hierarchy, you will be able to view all your subordinates’ records unless there’s a custom object your admin specifically set to to be inaccessible. Learn more here.
More on Sharing Rules
Sharing Rules allow you to completely disregard org-wide defaults and roles hierarchy for users, roles, territories, or public groups if records meet specific criteria.
For instance, using sharing rules, you can set up an environment where Sales Rep John should not have access to opportunity records he doesn’t own unless those opportunities are specifically owned by Sales Rep Mary or unless those opportunities have an Opportunity Type of “Existing Customer – Upgrade.”
How can this be implemented? With sharing rules!
In this case, two sharing rules can be created. The first sharing rule would state that if Mary is the opportunity owner, then give read/write access for these opportunities to John. The second sharing rule would state that if an opportunity has an Opportunity Type field value of “Existing Customer – Upgrade,” also share those records with John. In all other cases, John’s access to opportunity records is based on his position in the role hierarchy.
More on Manual Sharing
Manual sharing allows for one-time sharing of a record. This method is available as a button on the record page layout (if the admin has added it to the layout). For example, if John does not have access to Beth’s opportunities, but in this one instance Beth really needs John to see one of her opportunities, Beth can use the Sharing button on the record page to share the opportunity with John.
