Salesforce Role Hierarchy Design Guide

As a senior Salesforce developer at a Salesforce consulting company, I’ve designed dozens of role hierarchies to fit diverse business needs. In this guide, I’ll explain what role hierarchy is in Salesforce and how it works, discuss best practices for designing roles, and show examples of effective hierarchies. We’ll cover the key settings and steps (how to create, set up, and view roles), explain grant access using role hierarchy Salesforce by default, and show how role hierarchies interact with sharing rules and community users. Throughout, I’ll use clear, technical detail (with references) to ensure you have a complete understanding. 

Understanding a well-structured role hierarchy is essential for any Salesforce implementation company seeking to secure data while enabling collaboration. Let’s start with the basics.

What Is Salesforce Role Hierarchy?

The Salesforce role hierarchy is a built-in data security feature that defines how record visibility flows up through an organization’s roles. In simple terms, each role in the hierarchy represents a level of data access. A user assigned to a higher role automatically inherits access to records owned by or shared with users in roles below them. As Salesforce documentation states, “users can access the data of all the users directly below them in the hierarchy.”. In other words, if Alice is the Sales Manager above Bob (a Sales Rep) in the hierarchy, Alice can see Bob’s records (accounts, opportunities, etc.) even if the org-wide defaults are private.

Importantly, role hierarchies don’t have to match your org chart exactly. Instead, each role should correspond to a level of data access needed by a team or position. For example, you might consolidate multiple job titles under one role if they need identical access. The key is data visibility – roles just group users by what they should see. As Salesforce recommends, start with your company’s structure and “consolidate different job titles into single roles based on record access”.

By default, Salesforce enables grant access using hierarchies for every object (standard and custom). This means managers can see subordinates’ data unless a custom object has this setting disabled.

If “Grant Access Using Hierarchies” is disabled on a custom object, only the record owner and users granted access through sharing (or “View All” / “Modify All” permissions) can see the data.

In summary, the role hierarchy provides the base, vertical sharing model in Salesforce. A higher-level role can view or access data owned by users in lower-level roles. (Users on the same role level do not automatically see each other’s data – lateral sharing must use sharing rules.) This design ensures managers, directors, and executives have the visibility they need, while entry-level reps see only what’s theirs.

Salesforce Role Hierarchy Best Practices

Designing the role hierarchy carefully is crucial. A poorly planned hierarchy can expose too much data or become a maintenance headache. Here are key best practices:

Align the role hierarchy with real data-access needs

The hierarchy should reflect your organization’s structure to the extent necessary for security, not simply mirror titles. For example, if Customer Support and Sales have separate data, keep their chains distinct. Consolidate roles by access level, not just org chart. As a rule: each role in the hierarchy should represent a level of data access that a user or group needs. This means you can merge similar positions (e.g. “Junior Sales Rep” and “Senior Sales Rep”) into one role if they need identical visibility.

Use private OWD with a clear hierarchy

Set Org-Wide Defaults to the most restrictive level (often Private), and then open access via the hierarchy and sharing. With private defaults, a deeper hierarchy grants managers full view of subordinates’ records. Salesforce’s golden rule: “the org wide default should be set to the most restrictive level… Salesforce permissions work by opening up access, not by locking them down.”.

Keep the hierarchy simple

Avoid too many levels or branches that aren’t needed. Deep, convoluted hierarchies (for example, generic roles with thousands of users) can slow down sharing recalculations. In large orgs, deep hierarchies combined with private data can cause lock contention. Simplify roles wherever possible: merge sub-roles if they have identical supervisors, avoid needless intermediary layers, and don’t create roles “just because”.

Limit sensitive data exposure

Place truly sensitive records high up in the structure. If only executives should see some data, don’t put that data under public teams lower in the chain. Use field-level security or separate OWD/sharing rules for highly sensitive objects, rather than relying on hierarchy. Also, disable “Grant Access Using Hierarchies” on any custom object where managers shouldn’t see subordinates’ records (this is rare, but possible).

Combine roles with sharing rules

Role hierarchy handles vertical sharing (upward), but cross-functional sharing requires sharing rules or manual sharing. Plan to use sharing rules to share records horizontally or with people outside a branch. For example, if Marketing should see Sales opps, a sharing rule can grant Marketing Manager access to Sales records. As one guide notes, “Roles control visibility within a hierarchy, but sharing rules allow you to extend access across different roles or teams”. In effect, use the hierarchy for the main chain of command and sharing rules for specific exceptions.

Test and iterate in a sandbox

Always prototype your hierarchy with test users and data. Use test sharing rules and OWD settings in a sandbox to verify access. Check for unintended open access or hidden data. Salesforce recommends thoroughly “test your role hierarchy” to catch any misconfigurations.

Plan for scale

If your org will grow, consider grouping by business unit or function to make additions easier. Also be mindful of data skew (one user owning too many records) – ownership skew can cause “role hierarchy performance issues” as sharing recalculations spike. To mitigate skew, distribute record ownership or create additional roles under high-volume users.

Use reports/analytics to verify

After building roles, run reports filtered by role (using the “Filter by Role Hierarchy” option) to ensure managers see subordinates’ records. For compliance, you can even report which users see which data by role. (For example, create a user report including Role and filter “Show me = [My Role and Subordinates]” to list users in a branch.)

By following these best practices – aligning with actual data needs, simplifying structure, and combining with sharing rules – you ensure the role hierarchy provides secure, easy-to-understand access.

Managing and Configuring Roles

After planning, you must implement the hierarchy in Salesforce. Below are practical how‑to steps and considerations:

How to create role hierarchy in Salesforce

In Setup, enter Roles in the Quick Find box and click Roles (or Set Up Roles). On the Roles page (in tree view), click Add Role next to an existing role to make it a parent. Enter the new role’s Label and optionally a shorter role name (used in reports). For example, to add a Branch Manager under CEO, expand CEO’s node and click Add Role. Save, and then assign users to that role via Assign Users to Role. Repeat for all levels. Remember: after creating roles, assign each user to exactly one role. (Most users have only one role.)

How to set up role hierarchy in Salesforce

Design your top-level role first (often CEO or VP) by clicking Add Role on the placeholder org node. Then work downwards: for each department or team, add a role and specify its parent. In the Role Hierarchy setup page, use the tree view to visualize the structure as you add. You can also switch to a list view to quickly find roles by name. Salesforce saves the structure automatically. Once the tree is built, go back and Assign Users to Roles to match real people.

How to view/check/see role hierarchy in Salesforce

The Roles setup page itself shows the hierarchy. By default it displays the tree view (a nested list of roles). You can expand or collapse nodes to browse. In Lightning, you can also click Show Hierarchy on a user’s role detail to see the full reporting structure. For a quick check, run the SOQL query SELECT Name, Id, ParentRoleId FROM UserRole to see each role’s parent relationship, or use Workbench/Data Loader on the UserRole object. This lets you export or inspect the entire hierarchy.

How to grant access using role hierarchy in Salesforce

No extra setup is needed – it’s automatic. The Org-Wide Defaults (OWD) already assume “Grant Access Using Hierarchies” is on for standard objects. For custom objects, ensure OWD sharing defaults have the Grant Access Using Hierarchies box enabled (checked). This ensures managers get visibility. If a custom object’s OWD has this disabled, only owners and explicitly shared users can see records (even managers cannot). So as a rule, leave this setting enabled unless there’s a specific reason to block it.

How to combine sharing rules

Think of the role hierarchy as automatic vertical sharing, and sharing rules as manual lateral sharing. In Sharing Settings, define rules that match criteria or roles. For example, a rule could say “All users in the Marketing Manager role see all records owned by users in the Sales Manager role.” One common pattern: when separate branches need access, create sharing rules joining them. (E.g. share cases from Support to Sales Management when needed.) Sharing rules will execute in addition to the role hierarchy.

Salesforce community user role hierarchy

External users (partners or customers) can also have roles. For Partner or Customer Community licenses, Salesforce creates per-account roles. For instance, when you enable Partner Community for Account A, Salesforce auto-generates three roles under that account: “Account A Executive”, “Account A Manager”, and “Account A User”. These roles roll up under the parent account’s role. This means you get a separate mini-hierarchy for each customer/partner account. (Customer Community Plus users similarly have roles, usually named “<Account> Customer User”.) These community roles let account managers share data within that customer’s contacts while keeping accounts isolated from each other.

Salesforce query and export of role hierarchy

To analyze the hierarchy outside the UI, query the UserRole object. For example, a SOQL query like

SELECT Name, Id, ParentRoleId FROM UserRole

will return every role’s name, Id, and parent role. You can run this in Workbench, the Developer Console, or Data Loader. Exporting via Data Loader or workbench is common: enable “Show All Salesforce Objects”, select Role (UserRole), and export. That gives you a CSV of all roles and parent links, which you can review in Excel. You can also export the User table with profile/role fields to see who sits under whom.

Salesforce report on role hierarchy

In Lightning Experience, the report builder often lets you filter by role hierarchy. On a User or Activity report, you can add a filter “My Team” or “Show me: [User’s Role] and Subordinates”. This filters records owned by anyone under a given role. You can also include the user’s Role field in reports on objects like Tasks or Opportunities. If you need role names or IDs in a report, create a custom user report type and add “Role ID” via lookup fields, as outlined in Salesforce help.

Each of the above “how to” points corresponds to one of the listed keywords (how to create/view/check/set up…), covering them all in context. The table below summarizes common queries and methods:

CREATE/SET UP hierarchy: Setup → Roles → Add Role. Name it and choose a parent role.

VIEW/CHECK/SEE hierarchy: Setup → Roles → Show Hierarchy (tree or list view); or query UserRole.

GRANT ACCESS: Enabled by default via Grant Access Using Hierarchies in OWD.

SHARING RULES: Configure in Sharing Settings for cross-branch access.

QUERY/EXPORT: Use Data Loader or SOQL (SELECT Name, Id FROM UserRole) to export roles.

REPORTS: Use “Filter by Role” in reports or include Role fields on user-based reports.

Salesforce Role Hierarchy Examples

To illustrate, consider some typical hierarchies:

Sales Organization Example:

• VP of Sales (top role)
• Regional Sales Manager – East
• Sales Rep – East 1
• Sales Rep – East 2
• Regional Sales Manager – West
• Sales Rep – West 1
• Sales Rep – West 2

In this case, the VP of Sales can see all records owned by both Eastern and Western managers and reps. Each regional manager can see the records of their own sales reps. The individual sales reps only see their own records (unless sharing rules give them more).

Marketing Department Example:

• VP of Marketing
• Marketing Director – North America
• Marketing Coordinator – NA 1
• Marketing Coordinator – NA 2
• Marketing Director – EMEA
• Marketing Coordinator – EMEA 1
• Marketing Coordinator – EMEA 2

Here, the VP sees all marketing records. Each director sees only their region’s records. Coordinators see only their own.

Service (Support) Example:

• VP of Customer Service
• Service Manager – APAC
• Service Agent – APAC 1
• Service Agent – APAC 2
• Service Manager – Americas
• Service Agent – Americas 1
• Service Agent – Americas 2

In this hierarchy, each Service Manager can access the cases of their own agents, and the VP can access cases from all regions.

Below is a generic example diagram of a role hierarchy:

Figure: Example Salesforce role hierarchy (CEO at top, with separate branches for two business units). Users at a higher role (e.g. CEO) see records of all subordinates. Managers see only their branch.

These examples show how the hierarchy mirrors business structure to align access. In practice, you’d tailor the branches to your org. For instance, finance or HR might have their own branch distinct from sales. The diagram above (from Salesforce Architects) illustrates a CEO at the top with two branch managers below. This reflects best practice: the CEO role has full visibility, and each branch manager only sees their team’s data.

When designing, ask questions like “Who needs to see this data?” If the answer is “my manager should see it, and their manager as well,” then those roles should be linked upward in the hierarchy. If users in one department shouldn’t see another’s data, keep those branches separate (or use sharing rules for controlled exceptions).

Role Hierarchy and Sharing Rules in Salesforce

The role hierarchy and sharing rules work together. By default, the hierarchy automatically shares records upward. For example, with private OWDs, a case owned by a rep is visible to their manager and manager’s manager, etc. This is Salesforce role hierarchy sharing in action. No manual sharing rule is needed for that vertical access.

However, role hierarchy sharing only grants access along the chain. To share records across branches or between peers, use sharing rules. For example, if Sales Managers should see a particular Marketing campaign, create a sharing rule that shares that campaign with the Sales Managers’ role. As one expert notes, “Roles control visibility within a hierarchy, but sharing rules allow you to extend access across different roles or teams. Use sharing rules to provide access when cross-departmental collaboration is necessary”.

Importantly, sharing rules and role hierarchies are both subject to OWD. Hierarchy sharing cannot override a disabled hierarchy setting on an object. But in standard use (hierarchy enabled), managers get subordinate data automatically, and sharing rules fill in the gaps sideways. When combined with profiles and permission sets (for object-level and field-level security), you get a robust model where the right people see the right records.

Summary

In summary, the Salesforce role hierarchy is your first line of record-level security. It is a powerful sharing tool that opens access vertically: managers see subordinates’ data, cascade up through the chain. By designing the hierarchy to reflect actual data access needs (not just titles), and keeping it as simple as possible, you ensure users only see what they should. Combine the hierarchy with carefully crafted sharing rules to cover any cross-team access, and use the built-in setup tools (or SOQL queries) to manage and review the roles.

Key takeaways

Define roles by data access, not just org chart positions. – “Grant Access Using Hierarchies” is enabled by default; leave it enabled unless absolutely needed to restrict. – Use the Setup Roles page (tree view) to create and view your hierarchy. – Remember that role hierarchy sharing is above and beyond any sharing rules you set. Managers get subordinates’ records automatically. – In large orgs, watch out for ownership and data skew – avoid one user owning thousands of records (which causes “role hierarchy performance issues”). – Test your hierarchy with sample users and records, and use Salesforce reports filtered by role to verify visibility.

With a well-planned hierarchy, Salesforce role hierarchy becomes a seamless part of your data security model. It ensures that as people move up in their career (and change roles), their new role grants them the appropriate visibility automatically.