Create a Role Hierarchy

Learning Objectives

After completing this unit, you’ll be able to:

• Explain how the role hierarchy is different from an org chart.
  
• View and modify the role hierarchy.
  
• Create and assign roles to simplify access to records.
  

The Role Hierarchy and Record Access

The role hierarchy works together with organization-wide default sharing settings to determine the levels of access users have to your Salesforce data. Users can access the data of all the users directly below them in the hierarchy.

Users who need to see a lot of data (such as the CEO, executives, or other management) often appear near the top of the hierarchy. But role hierarchies don’t have to match your org chart. Each role in the hierarchy just represents a level of data access that a user or group of users needs.

Users at any given role level can view, edit, and report on all data owned by or shared with users below them in the role hierarchy. The only exception is for custom objects, for which you can disable access using hierarchies. Specifically, in the Organization-Wide Defaults related list, if the Grant Access Using Hierarchies option is disabled, only the record owner and users granted access through sharing features receive access to the object’s records.

Implementing the role hierarchy in the platform is easy once you have an idea of what the hierarchy should look like. It’s best to start with your company’s org chart and then consolidate different job titles into single roles based on record access wherever possible. Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.

For example, if a software development group has a staff software engineer and a junior software engineer, these positions can be consolidated into a single Software Engineer role in the hierarchy. Once that’s done, you can get started defining the role hierarchy itself.

Role Hierarchy for the Recruiting App

Let’s take a look at a branch of the role hierarchy for the example Recruiting app. Remember, with the org-wide defaults you defined, hiring managers are allowed to view (but not create or update) all position, job posting, and employment website records, and to view and update other recruiting records they own. That doesn’t make your app all that useful. However, you plan to set up your Human Resources roles so that users get access to the data they need.

This role hierarchy automatically grants these kinds of record-level permissions:

• The CEO, Cynthia, can view and update every record that anyone else in the organization can view and update.
  
• The VP of Development, Andrew, can view and update any record that his managers or his managers’ employees can view or update.
  
• The VP of Human Resources, Megan, can view and update any record that Phil, her recruiting manager, or Mario, Phil’s recruiter, can view and update.
  
• The Recruiting Manager, Phil, can view and update any record that is owned by Mario, his recruiter.
  
• The Software Development manager, Ben, can view and update any record that is owned by Melissa, Tom, or Craig, his software engineers.
  
• The director of QA, Clark, can view and update any record that is owned by Flash or Harry, his QA engineers.
  

Define ‌Role Hierarchy

Now practice setting up the Onboarding Manager role, which reports to the VP of Human Resources.

1. From Setup, in the Quick Find box, search for and select Roles.
   
2. If you see an introductory splash page called Understanding Roles, click Set Up Roles at the bottom of the page to skip to the actual tool.
   

The default view for this page is the tree view, as indicated in the dropdown list on the far right side of the Role Hierarchy title bar. When creating a role hierarchy, it’s probably easiest to stick with this or the list view, because they both make it easy to see how the roles all fit together in the hierarchy. The sorted list view is best if you know the name of a role that you want to find but aren’t sure where it fits in the hierarchy, or if you don’t want to click open all the tree nodes. For this unit, stick with the tree view. 

3. When you first start defining a role hierarchy, the tree view displays a single placeholder node with the name of your org. From this point, you must add the name of the role that is highest up in the hierarchy—in this case, the CEO. In your playground, some roles in the hierarchy are already defined. Click Expand All to see the whole role hierarchy.
   
4. Under the VP Human Resources role, click Add Role.
   
5. For Label, enter Onboarding Manager. The Role Name autopopulates with Onboarding_Manager.
   
6. In the This role reports to text box, leave the VP Human Resources role populated.
   
7. In the Role Name as displayed on reports text box, optionally enter a value. This text is used in reports to indicate the name of a role. Since a long role name takes extra space in your report columns, we recommend using a short but readable abbreviation.
   
8. Leave any other options, such as Contact Access or Opportunity Access, set to their defaults, and click Save. These access options don’t affect your Recruiting app. But normally, you configure the access the role has to the child records of accounts they own.
   
9. Now that you created your role, you can assign the appropriate user to it. Click Onboarding Manager, and click Assign Users to Role. 
   

10. In the Available Users dropdown list, select All Unassigned.
    
11. Choose a user from the list, and click Add to move the user to the Onboarding Manager list, then save.
    

If you return to the main Roles page from Setup, you can now see the new role in the hierarchy. Next, you can define the rest of the roles according to your diagram, like the Recruiting Manager and Recruiter roles.

To speed up the process of adding a new role, click Add Role directly under the name of the role to which the new role should report. When you do this, the This role reports to text box is automatically filled in with the name of the appropriate role.

As you can see, the role hierarchy is a powerful way to open up data for people who need to see a lot of it!

With org-wide defaults and a role hierarchy in place, you’re almost done with the record-level access permissions for the Recruiting app. All that’s left is to share recruiting-related records between groups that appear in separate branches of the role hierarchy. You can accomplish this requirement with sharing rules.

Resources

• Salesforce Help: Set Up Record Access for Your Users
• Salesforce Help: Controlling Access Using Hierarchies