Roles, Super Users, Account Hierarchies

Module 9 of 9 in the chapter Steve’s 25 Ways to Share a Record: The Map, chapter 5 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When customers and partners have their own managers and their own companies inside your org, how do their records flow up and across, and after 25 ways, where do you look to find out who can see a record?

Set 7 was for the cheap seats, users with no role. Set 8 is for the seats with cushions: Customer Community Plus and partner users, who do have roles. And once they have roles, their own structure starts sharing records: their managers, their super users, and their parent companies. Three ways: the external role hierarchy, super users, and external account hierarchies.

Then, because this is the last module, we’ll step back and look at the whole map one more time.

Click to enlarge

Way 23: the external role hierarchy

Here’s the picture. Say you’re a plumbing-supply company, and a channel manager owns three customer accounts. When you turn on external users for those accounts, Salesforce creates roles for each one, as child roles under the account owner. You decide how many: “Number of customer roles: You can have up to three roles.” For partners, “a user role hierarchy is created for that account. The three roles are Partner User, Partner Manager, and Partner Executive. The role hierarchy rolls up to the account owner (typically, the channel manager)” (Configure Digital Experiences Settings (opens in a new tab), Salesforce Help, checked 2026-11-01).

So now your role hierarchy has a customer’s manager and a customer’s user under every account, often with the account’s name in the role. That’s how it gets the automatic rollup. If a user at the customer creates a record, their manager at that company sees it, then the channel manager sees it, and all the way up your hierarchy, the same way as module 2.

Two things to watch. The roles multiply: two roles for each of thousands of accounts is thousands of roles, and that’s real weight on the hierarchy. Chapter 14 covers how to keep it down. And choose the number at the start: “If you specify one customer role and then decide to increase the number of roles later, the increased number of roles isn’t applied to existing customer accounts” (same page).

Way 24: super users

A super user is an external user, not an internal one. There are two kinds: a partner super user and a customer super user.

Partner super users “can get insights into the records of other partner users who are at their role level or below them in the account role hierarchy.” It “applies only to cases, leads, custom objects, and opportunities,” and they get access “based on their user permissions”: a manager with read-only access to cases only views them, even as a super user (Grant Portal Super User Access to Partner and Customer Users (opens in a new tab), Salesforce Help, checked 2026-11-01).

Customer super users get the Portal Super User permission, for Customer Community Plus users. It lets them “View, edit, and transfer cases,” “Create cases for contacts,” and “View and edit all contacts” on their account (same page). They see what their company has, not just what’s theirs.

Now a correction to a story I’ve told in class. A salesperson signs up a new customer and creates the first user there. Then the customer says, we have fifty more people. Who’s going to type them all in? Not your salesperson. I used to say: make that first user a super user, and they’ll add the rest. But that’s a different permission. The Portal Super User permission gives access to the account’s cases and contacts “without permission to manage other external users” (same page). Adding and managing coworkers is the Delegated External User Administrator permission: with it, an external user can “create and edit a member, reset a member’s password, and activate or deactivate a member” (Delegate Site Administration to an External User (opens in a new tab), Salesforce Help, checked 2026-11-01).

So the story still works, with two permissions. A super user sees their coworkers’ records. A delegated external user administrator adds their coworkers. Often it’s the same person, given both on purpose.

Way 25: external account hierarchies

The last way on the map. Sometimes your customer isn’t one company, it’s a family of them: a parent company and its regional offices, each its own account. An external account hierarchy links them, so “Account records owned by users with roles in child accounts that are part of an external account hierarchy share data with the parent accounts in that hierarchy” (External Account Hierarchies Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).

So the people at the parent company see what the regional offices own. “Child account data is shared with the highest role at each level within the external account hierarchy” (same page).

Know the limits before you turn it on, all from the same page:

• Only for seats with roles. “This feature is available in orgs with Partner or Customer Community Plus licenses.”
• Five levels. “You can add up to five hierarchical levels in an external account hierarchy.”
• One kind of account. “The hierarchy can contain either a partner account or a customer account, but not both,” and only “business accounts, not person accounts.”
• Not with account role optimization. “External account hierarchies are incompatible with account role optimization (ARO).”
• The internal owner loses something. “Internal owners of child accounts that participate in an external account hierarchy can’t manage external users in the account that they own.”

And like account relationships in module 8, it’s one-way: “After you enable this option, you can’t disable it in your org” (Configure Digital Experiences Settings).

What the share table doesn’t show

That’s all 25 ways. Now step back.

All through this chapter, we watched one account’s share table grow. The owner’s row in Set 1. Rule rows in Set 2. Manual, team and territory rows in Set 3. The implicit parent row in Set 4. Your own code’s row in Set 5. In class I say: some mechanisms are in the share table and some are not. Some people don’t even know what the share table is. Now you know both halves.

Here are the ways that never write a row:

• The org-wide default isn’t a row. It’s where the rows start (module 2).
• The role hierarchy isn’t stored as rows either: “The role hierarchy is not maintained with sharing records. Instead, role hierarchy access is derived at runtime” (Understanding Sharing (opens in a new tab), Apex Developer Guide, Winter ‘27, checked 2026-11-01).
• View All, Modify All and system mode read past the table (modules 5 and 6).
• Child implicit access to cases and contacts hasn’t been stored since Summer ‘23 (module 5).
• Sharing sets store nothing: “For some sharing mechanisms, such as sharing sets, sharing entries aren’t stored at all” (AccountShare (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-01).
• Restriction and scoping rules filter what the table opened (module 7).
• Data categories are a model of their own (module 5).

And one warning from the same AccountShare page: “it’s possible that we’ll stop storing certain share records to improve performance. As a best practice, don’t create customizations that rely on the availability of these sharing entries.” Read the share table to understand. Don’t build on rows you didn’t write.

So when someone asks how a user can see a record, the share table is where you start, not where you finish.

Click to enlarge

Beyond the record

The 25 ways answer one question: can this user open this record? There’s more in the building than records, and each of the other cabinets has its own rules for who sees what:

• Files. Who sees a file isn’t decided by the share table. A file can be private, shared with people or groups, attached to a record, or shared by link. Chapter 12.
• Folders. Reports, dashboards and email templates live in folders, and the folder decides who sees them. Chapter 12.
• Knowledge. Articles follow their data categories, way 15, and the channels they’re published to. Chapter 12.
• Analytics. CRM Analytics datasets have row-level security of their own; they don’t simply follow the record’s sharing. Chapter 12.
• What a user may run and use. Which flows they may run, which apps and credentials they may use, and which agents they may talk to are grants on the permission set, for people, integrations and agents alike. Chapter 3, module 7, and chapter 17.
• What’s inside a field, and who looked. Encryption, chapter 18, and monitoring, chapter 19.
• Agents and Data 360. Agents read through every cabinet as the user they run as, chapter 20. Data 360 is near core, with a model of its own: data spaces and policies, not the share table. Chapter 21.

Where this goes deep

Chapter 14, External Users: Sites, Communities, Licenses and Roles, takes Set 8 apart: external roles and how many, super users, delegated external administration, and external account hierarchies. And the whole of Part 2 and Part 3 follows the map, set by set, as module 1 laid out.

What an architect decides here

• How many external roles each customer and partner account gets, chosen before the first account is enabled.
• Who at each customer or partner is a super user, and who is a delegated external user administrator, as two separate decisions.
• Whether customer or partner families need an external account hierarchy, knowing it can’t be turned off and doesn’t work with account role optimization.
• For any “who can see this record?” question, which of the 25 ways to check, starting with the share table and not stopping there.

Beyond the exam: what AI changes. An agent on a partner site answers as the partner user, and that user’s place in the external hierarchy decides what it can find. Give a partner executive’s agent a question about their region, and it reads everything their super user access and their account hierarchy reach. Test it with the partner user who should see the most, and the one who should see the least. Chapter 20 covers agents.

Explore

• Configure Digital Experiences Settings (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Grant Portal Super User Access to Partner and Customer Users (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Delegate Site Administration to an External User (opens in a new tab), Salesforce Help (checked 2026-11-01)
• External Account Hierarchies Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Understanding Sharing (opens in a new tab), Apex Developer Guide (checked 2026-11-01)
• AccountShare (opens in a new tab), Object Reference (checked 2026-11-01)