Salesforce: The Role of the Role Hierarchy

You might think your Salesforce Role Hierarchy should match your company’s org chart exactly. It makes sense … the Role Hierarchy has “roles” and they report to other “roles” … on up the food chain, right?

Don’t just copy your company’s org chart to your Salesforce Role Hierarchy

However, the number of roles in your company’s org chart nearly always exceeds the number of roles you need to build an appropriate Salesforce Role Hierarchy.

I’ve seen many companies do this — build out their entire company org chart in their Salesforce org’s Role Hierarchy. I want to explain why it is not a best practice by showing what Salesforce Roles are and aren’t.

“Role” On

Here’s where Salesforce Roles are useful:

1. Viewing Records of Child Roles

If you are using private org-wide security settings for your Salesforce org, the Role Hierarchy grants visibility for users who have parent roles to the records owned by users in their child roles. The Role Hierarchy is one of the following trinity of Salesforce permission controls that you use to establish record visibility for Salesforce users:

• Org-Wide Defaults (OWD)
• Role Hierarchy
• Sharing Rules

Remember that a user’s Profile controls which objects the user can see, while the OWD/Role Hierarchy/Sharing Rules control which records in those objects the user can see.

Also, when trouble-shooting permissions issues, keep in mind that if (for any object) users only see their own records and those of their subordinates, the permission set up for that object is Private (or “Controlled by Parent,” when the parent object’s default internal access is “Private”) and there are no additional sharing rules for that object — at least for the user(s) you are trouble-shooting.

If you are not using private org-wide security settings, the following still may apply, but consider whether you need a Role Hierarchy at all.

2. Rolling Up Data on Reports/Dashboards

If a manager needs to regularly review records created by those who report to him/her, Roles allow the visibility of his/her team data in reports and dashboards.  When building these reports with data that rolls up from all subordinates to the next level in the Role Hierarchy, set the “Show” drop-down to “My Team’s {name of object}, as shown for an Account report at left. The team members will see their own data; the manager will see all.  

Example: a Sales Manager, who looks at the pipeline his/her team is responsible for.

3. Automatically Include Users in Public Groups

Another function that Roles can accomplish is to automatically place users in Public Groups. Public Groups can be used:

• to manage visibility to folders and views
• to assign permissions using sharing rules
• to grant Library and Knowledge action permissions

Including Roles, or “Roles and their Subordinates,” in a Public Group can take some of the guess-work out of setting up new users because you don’t need to figure out what Public Groups to add them to.

(For those of you who are active on the Idea Exchange, vote up this idea to see where groups are used.)

4. The Forecast Hierarchy

The Forecast Hieararchy is a copy or your Role Hierarchy to which you can add Forecast managers. Forecast Managers must be added to the Forecast Hierarchy in order for your forecasts to roll up. Focus only on the branches of the Forecast Hierarchy that pertain to your Sales team and assign Forecast Managers to each node. There is no need to assign Forecast Managers for portions of the Role Hierarchy that are not involved in revenue forecasting.

If your organization has enabled territory management (only available with Customizable Forecasting), the Territory Hierarchy is used exclusively for forecasting and the Role Hierarchy does not apply to forecasting.

5. Reports and the Role Hierarchy

When building reports using standard report types, you can save the hierarchy level. Such a report associates the hierarchy with the data. Someone within the hierarchy can view the data at any subordinate role level. However, this does not allow a user to see records that s/he would not otherwise see.

You can click any Role in the saved hierarchy (if necessary, first click Show Hierarchy) on that report, to see the data as that Role, provided that you have access to that Role’s data or above.

 Slow Your “Role”

There is no reason to add a Role in Salesforce if any of these are true:

1. No one who has that job title in the company org chart has a Salesforce User license

If there are no users with a particular job title in Salesforce, then there is no reason to add a Role for that job title. It just makes more maintenance work and adds no value.

2. Two or more job titles reporting to the same manager

Likewise, there is no reason to add diff犀利士5mg
erent roles for different job titles that are subordinate to the same manager’s role. Unless you need to aggregate records owned by each role separately, those job titles do not need to be separate roles.

Having separate roles in this case, will keep the data from each peer role (child of same parent) separate, as long as the OWD for this object is set to “Private.” If records owned by one Role — say, “Assistant” — should be visible to all the other users who are subordinate to the parent role, the “Assistant” role can be a child of that child role.

3. Everyone sees everything

If the Org-Wide Default permissions on your Salesforce objects are Public, you do not need to add separate Roles for the users. The Role Hierarchy allows for users with parent Roles to see records owned by users in subordinate Roles. If your OWD are Public, the Role Hierarchy will not matter, except in the case of limiting reports/dashboards to records owned by a particular team (see #2 above).

If you share all records among all Salesforce users, the only use of the Role Hierarchy is for aggregating data in this way.

Bottom Line

Someone has to support and maintain the Role Hierarchy. It’s not just another way to make sure everyone knows the pecking order. (Take a look at how often users with the Roles at the top nodes log in before you indulgence this silliness.)

Roles Gone Wild aren’t simple to clean up, and they don’t add anything but drag – and possible sources of error – to your Salesforce org.