Welcome to Record Access, one of the Who Sees What series.
These videos provide the basics on visibility and data access in Salesforce.
We’ve given users access to the organization by setting IP ranges, and login hours,
we’ve granted users access to objects through profile permissions and
We’ve set our organization-wide default sharing settings.
Now its time to talk about roles, and the role hierarchy.
The role hierarchy is a way to extend access to records, when org-wide sharing settings
have been set to anything more restrictive than Public Read/Write.
Before we get into the role hierarchy, let’s review the current setup at AW Computing.
So far, we have 2 profiles in use: We created a custom profile and assigned it
to all of our Inside Sales Reps.
All other users are assigned the Standard User profile.
And we set our org-wide defaults which determine the access users have to records they do not
own.
Lets go into detail.
Since the org-wide defaults for opportunities are private, users cannot see each others
opportunities.
Only the user who owns the record can view it, search for it, or see it in reports.
However, at AW, the sales managers need to see the opportunities that their teams are
working on, so they can run reports, and analyze the sales pipeline.
Sales Operations work on opportunities with both the inside sales reps and the managers,
so they need to see all opportunities.
You can use the role hierarchy to open up record access when the org-wide default is
set to anything more restrictive than Public Read Write.
The hierarchy at AW Computing should look something like this:
Sales Ops are at the top level, so they can see records owned by roles beneath them,
the Sales Manager can see all records below them, and beneath the managers are the Inside
Sales Reps.
Since Opportunities are Private, the role hierarchy allows us to open up access in 1
of 3 ways.
For each role, we could choose 1 of the following: No Access.
In essence, this maintains the org-wide default of Private.
Users in this role would not be able to see opportunities they do not own.
We’ll use this for the inside Sales Rep role.
View Only.
Users in a role can view opportunities, regardless of ownership.
We’ll choose this option for the sales manager role.
Or we can choose View and edit.
Users in a role can view and edit opportunities, regardless of ownership.
This is the option we’ll pick for the Sales Ops role.
Let’s take a look at this in our demo org for AW Computing.
We’re going to set up the role hierarchy at so that our users have access to the records
they need.
The role hierarchy is located in the Setup pages, under manage users, roles.
The role hierarchy has already been partially set up for us.
We can see that all the VP level roles are under the CEO, giving the CEO access to all
records owned by any users in those roles AND any roles under the VPs.
We can see that the Inside Sales Reps are under the US Sales Manager role.
Let’s check the access settings for the Inside Sales Reps.
In the Opportunity Access area, we’ll choose “Users in this role cannot access opportunities
they do not own…”
Since the org-wide default for Cases is also private, we have the same 3 options available.
For the Inside Sales Reps, we’ll choose to allow them View access to cases, since
it will be helpful to them to know whether or not a customer is having an issue.
Now let’s check the Sales Manager Role We’ll make sure they have View access to
opportunities, so they can see all opportunities below them in the hierarchy.
And View access to cases as well.
Now let’s add a new role for Sales Operations.
we’ll click Add Role We’ll fill in the labels -
And We’ll click the Lookup icon in the “reports to” field and select the VP of Global Sales.
We want Sales Operations to be able to view and edit all opportunities owned by any users
beneath them in the hierarchy, so we’ll choose the “Edit” option for Opportunity
access.
It will be useful for Sales Ops to see cases associated with accounts or opportunities
they are working with, so we’ll choose “View” for Case access.
And click Save.
Now we’ll assign Alan Wong and Tony Jenkins to this role
And click Save We’ll go back to the role hierarchy
Now we’ll move the US Sales Manager under Sales Ops.
All roles beneath the Sales Manager will move as well.
Click Edit next to US Sales Manager In the “Reports to” field, use the Lookup
button to choose Sales Ops And we see that the entire hierarchy from
US Sales Manager on down, has been moved under the Sales Operations role.
Nice work – we’ve set up the role hierarchy and granted the proper record access to our
users.
Let’s see these settings in action with Alan Wong, one of our employees in Sales Ops.
If Alan’s profile grants him Create, Read, Edit, and Delete permissions on the Opportunity
object, and the Org-wide defaults are set to Private on Opportunities, then we can grant
him any of the 3 options to Opportunity records below him in the hierarchy.
If we change Alan’s profile to grant only Create and Read, and leave the Org-wide defaults
the same, the role hierarchy will offer us the same options.
However, even if we choose View + Edit, Alan will still be unable to Edit opportunities,
since his profile does not grant him that permission.
Remember, the role hierarchy cannot grant a user more access than they have through
their profile permissions.
If Alan’s profile grants full CRED on all the Opportunity object, and the Org-wide defaults
are set to Public Read Only on Opportunities, Alan can see records owned by other users,
and if those owners are below him in the hierarchy, the roles settings will provide us with 2
options: view, or view and edit.
The “No Access” option doesn’t appear since the Role Hierarchy can only open up
access to records.
It cannot restrict record access to less than what is granted thru the org wide defaults.
If we change Alan’s profile to grant only Create and Read access, and leave the Org-wide
defaults the same, Then he has Read Only access to Opportunities.
Neither the Org-Wide defaults nor the role hierarchy can grant him Edit access.
The “View and Edit” option will be available but won’t apply to Alan, since he does not
have Edit permissions on his profile.
If Alan’s profile grants full CRED, and the Org-wide defaults are set to Public Read/Write,
then the role hierarchy here is not necessary.
Alan already has access to all opportunities through his profile and the org-wide defaults.
If we change Alan’s profile to grant only Create and Read, and the Org-wide defaults
are set to Public Read/Write, then he has access to all opportunities, but only the
ability to Read them, since neither the org-wide defaults nor the role hierarchy can grant
more permissions than the profile.
For more information on the topic of visibility and access, please watch the rest of this
video series.
In addition, you can search for these topics in Help and Training.
Thanks for using Salesforce!