Construct a role hierarchy in Salesforce | Techila
single,single-post,postid-2612,single-format-standard,ajax_updown_fade,page_not_loaded,,qode_grid_1300,footer_responsive_adv,hide_top_bar_on_mobile_header,qode-content-sidebar-responsive,qode-theme-ver-9.4.2,bridge,wpb-js-composer js-comp-ver-4.12,vc_responsive

Construct a role hierarchy in Salesforce


Construct a role hierarchy in Salesforce

Salesforce offers a user role hierarchy that you can use with sharing settings to determine the levels of access that users have to your Salesforce org’s data. Roles within the hierarchy affect access on key components such as records and reports.

Users at any role level can view, edit, and report on all data that’s owned by or shared with users below them in the role hierarchy, unless your Salesforce org’s sharing model for an object specifies otherwise. Specifically, in the Organization-Wide Defaults related list, you can disable the Grant Access Using Hierarchies option for a custom object. When disabled, only the record owner and users who are granted access by the organization-wide defaults receive access to the object’s records.

Roles determine user access to cases, contacts, and opportunities, regardless of who owns those records. The access level is specified on the Role Edit page. For example, you can set the contact access so that users in a role can edit all contacts associated with accounts that they own, regardless of who owns the contacts. And you can set the opportunity access so that users in a role can edit all opportunities associated with accounts that they own, regardless of who owns the opportunities.

After you share a folder with a role, it’s visible only to users in that role, not to superior roles in the hierarchy.


Before looking at how to build an awesome role hierarchy, it is important to distinguish between a role and profile and why roles are so important.

If we simplify the definition of role vs profile to the most basic level, we get this: roles determine what data you can see and profiles determine what you can do with that data. That’s it! While in practice this is more complicated and there is a bit of overlap, this basic concept will help in differentiating between a role and profile.

To fully understand the function of roles, you need to be familiar with the concept of organization-wide defaults and how data visibility works by default. We know that owners of records, by default can create, view, edit and delete the records that they own. If the org-wide defaults are set to private, the no one in the organization has access to those records – except through the role hierarchy. This is where things get interesting. By default, data flows up the hierarchy. So, in an organization where record access is set to private, managers have at least read access to the records owned by their subordinates.

Now, what if the records you and your team owns need to be shared with a different department or role within the organization? We use sharing rules to share laterally across roles. Take a look at this image which illustrates how data flows vertically up the hierarchy and how sharing rules open data access laterally across the hierarchy.

Okay. Let’s see how to build an awesome hierarchy. Whether you are building a role hierarchy from scratch for a new organization, or you are needed to rebuild a role hierarchy for your existing organization, the steps will be the same. Just like building a house, you always lay the foundation first. That is all we are doing with these first steps.


Every company has an org chart which is already set up in a hierarchical structure. If you aren’t sure that an org chart exists, check with your HR department. After obtaining the org chart, do any reformatting you need to so that it is easy to read and manipulate. There are a number of tools do this with including Excel, PowerPoint or Visio. I recently found a great Google Apps plugin called Lucid Chart which is like a cloud version of Visio but with collaborative features.

Be sure to validate any changes you make with the appropriate department heads. The initial structure needs to be as exact as possible in order to provide a good launching pad.


Next, take some time to understand how your organization wants to share data. Who should have access to what – including CRED (create, read, edit, delete) and Org Wide Defaults. This will help us build sharing rules for the new role structure and create the appropriate org-wide defaults. It also helps in understanding how the org chart may need to be manipulated to fit into the role hierarchy based on those sharing rules.


A few key items to remember here:

  • Role hierarchies may not resemble the org chart 100%. Each one serves a specific purpose. The org chart is a great starting place but don’t be afraid to revise it when creating the role hierarchy based on requirements.
  • If possible, don’t create a 1:1 relationship between a role and a user. Keep the hierarchy as simple as possible and group roles together based on the necessary access level to data based on sharing rule requirements.
  • Print several versions of the hierarchy and use colors to indicate sharing rules across the organization. I find that traditional pen and paper works well while finalizing the sharing rules.
  • After documenting the sharing rules, update your hierarchy document showing the sharing rules and once again, confirm with the department heads that they are correct. Once validated, you can begin making your changes to both the role hierarchy and sharing rules.



“Know more about Salesforce Consulting at Techila”

Author: techila

No Comments

Post A Comment