This video brought to you by at Salesforce docs! Welcome to Record Access, the fifth
in the Who Sees What series. These videos provide the basics on visibility and data
access in Salesforce. We’ve given our users access to the organization
by setting IP ranges, and login hours, we’ve granted them access to objects through
profile permissions, and we’ve set our organization-wide default
sharing settings. Now it's 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. Everyone else was assigned the Standard User
profile. And we set our org-wide defaults which determine
the access users have to records they don’t own.
Let’s go into detail. Since the org-wide defaults for opportunities are private, users
can’t see each others opportunities. Only the user who owns the record can view it or
see it in reports. However, at AW, the sales managers need to
see 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 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 lets us open up access in 1 of 3 ways. For each role, we can choose 1 of the
following: No Access: In essence, this maintains the
org-wide default of Private. People in this role aren’t able to see opportunities they
do not own. We’ll use this for the Inside Sales Rep role.
View Only: People 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: Those 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
so that everyone has access to the records they need.
The role hierarchy is located in the Setup pages, under Users, Roles.
The role hierarchy is already partially set up for us.
All the VP level roles are under the CEO, giving the CEO access to all records owned
by anyone in those roles AND any roles under the VPs.
We 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 choose
“Users in this role cannot access opportunities they do not own…”
Since the org-wide default for Cases is also private, the same 3 options are available.
For the Inside Sales Reps, we choose View access to cases, since it’s helpful to them
to know whether or not a customer is having an issue.
Now let’s check the Sales Manager Role We 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.
Click Add Role Fill in the labels -
And 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 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 select “View” for Case access.
And Save. Now we assign Alan Wong and Tony Jenkins to
this role And Save
Going back to the role hierarchy Wemove the US Sales Manager under Sales Ops.
All roles beneath the Sales Manager will move, as well.
Edit the 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.
And we’re done! – we’ve set up the role hierarchy and granted the proper record access.
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 offers us the same options. However, even if we choose View
+ Edit, Alan is unable to Edit opportunities, since his profile doesn’t 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 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 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 through
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. The Org-Wide defaults and the role hierarchy
can’t grant him Edit access. The “View and Edit” option is available
but doesn’t apply to Alan, since he doesn’t 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 the org-wide defaults
and role hierarchy don’t grant more permissions than the profile.
To learn more about visibility and access, check out all the titles in this video series.
You can also search for these topics in Salesforce Help
And come join us on the trail at trailblazer dot salesforce dot com