Skip to content
SteveTechArcSteveTechArc Courses

Start at the Top of the Hierarchy

Module 5 of 7 in the chapter Org-Wide Defaults, Ownership and the Role Hierarchy, chapter 6 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: The role hierarchy sends every record up to the top. When a record must not reach the top, how do you design it so it doesn’t?

Here’s a simple question I ask in class. A case is owned by a service agent, and Grant Access Using Hierarchies is on. Who gets to see the case? The owner, and everybody above the owner. Good.

Now, what if that case is a complaint, and it says the CEO has been harassing me? Does the CEO get to see the case?

Right now, they do.

And it isn’t only harassment. Think of HR cases: I got married, I got divorced, and I need a case to record it. Then the CEO types into global search, and all of a sudden finds out about the divorce proceedings. If data goes into your org, it’s owned by users, and the hierarchy is on, it will go all the way up to the top.

Chapter 1, module 3 told this story to explain need to know. This module is the design: what you can do about it, what each choice costs, and what gets through anyway.

The first place I look: the top

Section titled “The first place I look: the top”

When someone tells me an org holds confidential data, the first thing I do is go look at the top of the hierarchy. Who’s at the top? That person gets to see everything owned below them, because of that one checkbox. So start at the top, and work your way down.

For cases you can’t turn that checkbox off. It’s a standard object, and for standard objects, the hierarchy always shares upward. Salesforce lets you turn it off only for custom objects (Create a User Role (opens in a new tab), Salesforce Help, checked 2026-11-07). So for a confidential case, the question becomes: who owns it, which branch are they in, and what’s at the top of that branch?

Some companies take the biggest step of all. I’ve seen a client run one org for their business data and a second org for HR. That works, and it costs you a second org to run. Most companies keep one org, and design for it.

Own it in a branch that starts at the top

Section titled “Own it in a branch that starts at the top”

In class, a student suggested a peer for the CEO: a role at the same level, with a subtree under it. Good instinct, but watch where the peer sits. If it’s equivalent to a VP, it’s still under the CEO, and the CEO will see it.

If you want to keep a record out of normal visibility, it has to be owned in a branch of the tree that starts at the top of the hierarchy. A role such as HR Confidential, with nothing above it. The HR case managers sit under it. A complaint they own climbs to HR Confidential, and stops. The CEO, the service manager and the service agent don’t see it.

The CEO and the complaint, three ways A role hierarchy drawn as a tree. On the left, the CEO at the top, a service manager under the CEO, and a service agent under the manager. Beside it, a level below the CEO but not connected to it, a dashed box marked Confidential branch: HR Confidential, a top-level role with nothing above it, and an HR case manager under it; a red arrow toward the CEO is crossed with an X. On the right, on its own, an HR case owner: a user with no role, not in the tree. First frame: the service agent owns the complaint, and it climbs to the service manager, who sees it, and on to the CEO, who sees it although the complaint is about them (marked in red). Second frame: the HR case manager owns the complaint, and only HR Confidential sees it; the CEO, the service manager and the service agent can't. Third frame: the HR case owner with no role owns the complaint, and nobody else sees it through the hierarchy. Underneath: look at the top of each branch; whoever is there sees everything below. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-SVA-OH-09", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "tree 0.1.0", "theme": "stevetecharc 1.4.0"} CONFIDENTIAL BRANCH CEO the complaint is about this person can't see it Service manager manages the service team can't see it Service agent took the call can't see it HR Confidential a top-level role: nothing above it can't see it HR case manager handles confidential cases can't see it HR case owner a user with no role: not in the tree owns the complaint Look at the top of each branch: whoever is there sees everything below. HOW TO READ IT rolls up: every role on the path sees what is below it owns the record doesn't roll up to the CEO a branch of its own © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Two things to check in that branch. First, the people above the owner inside the branch still see it, so the branch needs to be built for that, too. Second, nobody from outside should be added under it later because it was a handy place to put them. Every person you put under HR Confidential now sees what’s below them.

Or an owner with no role

Section titled “Or an owner with no role”

The other way is to make the record owned by a user who has no role. A user with no role isn’t in the tree, so there’s nobody above them. The hierarchy has nowhere to send the record.

It has a cost. With no role, a lot of the ownership-level sharing is affected. No manager sees that user’s records through the hierarchy, even the ones who should. And Salesforce keeps a group for every role (module 1), so a sharing rule that picks owners by their role has no role to pick this user by. You open up access some other way, on purpose.

So this can be a fundamental decision. If you have a confidential object, a confidential patient object, a confidential HR object, a confidential case object, you need to look at who’s going to be the owners, whether they’re in a branch, and what’s at the top of their branch. Some of the first questions you should be deciding.

Three more tools for the same job

Section titled “Three more tools for the same job”

A queue with its hierarchy switch off. Module 3 showed that each queue has its own Grant Access Using Hierarchies setting. Leave it off for an HR complaints queue, and the queue’s members see the complaints while the managers above them don’t (Create Queues (opens in a new tab), Salesforce Help, checked 2026-11-07). But watch what happens next. When a member takes ownership, the case leaves the queue, and now a user owns it. That user’s hierarchy applies. So the queue protects the record only while the queue owns it. The person who takes it must sit in the confidential branch, or have no role.

The hierarchy turned off, for a custom object. This is the strongest of them. On a custom object, turn off Grant Access Using Hierarchies in Sharing Settings. Then “only the record owner and users who are granted access have access to the custom object’s records” (Create a User Role). Nothing rolls up, from anyone. That’s one more reason to give confidential data its own custom object, instead of a record type on a shared one. Chapter 4, module 4 makes that case.

A restriction rule. In class, a student asked whether a restriction rule would do it. I said yes, and for the right object, it does. A restriction rule takes the records a user can already see, through the default, the hierarchy and every other way, and filters them down to the ones that match your criteria. It applies to records, list views, lookups, related lists, reports, search, SOQL and SOSL (Restriction Rules (opens in a new tab), Salesforce Help, checked 2026-11-07). Put a Confidential checkbox on the record, and a rule hides the checked records from everyone the rule applies to.

But check which objects. When I checked on 2026-11-07, “Restriction rules are available only for custom objects, external objects, quotes, contracts, events, tasks, time sheets, and time sheet entries.” Cases aren’t on that list, so for the confidential case in my story, a restriction rule isn’t an option today. And there’s a limit: “up to two active restriction rules per object in Enterprise and Developer editions and up to five active restriction rules per object in Performance and Unlimited editions” (same page). Chapter 16 takes restriction rules apart.

One more, for later: a public group can also block the hierarchy, so a record shared to the group stays with the group’s members. Salesforce describes groups where “the data will be accessible ONLY to group members, and nobody else in the organization” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07). That’s about what you share to the group. The owner and the owner’s managers still have their access. Chapter 7 covers groups.

What gets through anyway

Section titled “What gets through anyway”

Every one of those tools is about sharing. Some permissions don’t ask the sharing model at all.

  • View All and Modify All on the object. They “ignore sharing rules and settings” (Platform Sharing Architecture). Whoever has View All on cases sees every confidential case, whatever branch owns it.
  • View All Data and Modify All Data. These go further: they “allow users to view or modify all apps and data” (same page). And a restriction rule doesn’t stop either of them: “Users with the View All Records or View All Data permissions can view all records regardless of restriction rules” (Restriction Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07).
  • Code running in system mode. “Restriction rules aren’t applied for code executed in System Mode” (same page). Chapter 17 covers secure code.
  • Every other way of sharing. Module 1 showed that inside the cabinet, the most generous reason wins. Keep the record out of the hierarchy, and one manual share, one sharing rule or one team member added later opens it again.
Keeping a confidential record from the top Five ways to keep a confidential record from the top, and what gets through anyway. A branch of its own: it climbs only to the top of that branch, and the roles above the owner inside the branch still see it. No role: nothing above the owner, so no manager sees it, and rules that pick owners by role can't pick this one. A queue with its hierarchy switch off: the members see it and their managers don't, but only while the queue owns it. The hierarchy turned off: custom objects only; only the owner and the people granted access. A restriction rule: filters what users can already see, on the objects that support it, not cases; two or five rules per object. What gets through anyway, in red: View All and Modify All on the object, View All Data and Modify All Data, and code in system mode. Footnote: look at the permissions at the top, not only the branch. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-SVA-OH-10", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} A branch of its own a top-level role Climbs only to the branch top Roles above the owner still see it No role nothing above the owner No manager sees it Role-based rules can't pick the owner A queue, hierarchy off the queue's own switch Members see it, managers don't Only while the queue owns it Hierarchy off custom objects only Owner and people granted access Nothing rolls up, from anyone A restriction rule filters what users already see Not for cases Two or five rules per object Gets through anyway doesn't ask the sharing model View All, Modify All View All Data, Modify All Data Code in system mode Look at the permissions at the top, not only the branch. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

So when you go look at the top of the hierarchy, look at its permissions too. Does the CEO have the System Administrator profile, or a permission set with View All Data? Then the branch you built doesn’t matter for that person.

And hiding the record is only half of it. Even when the record is locked down, its name, its files and its search results can bleed. Chapter 4, module 4 covers data bleed, including the day I found people’s reviews in global search, and the question every student asks next: how do leaders see the totals without the details?

What an architect decides here

Section titled “What an architect decides here”
  • For each confidential object, who owns its records, which branch they’re in, and who sits at the top of that branch.
  • Which way keeps it from the top: a branch of its own, an owner with no role, a queue with its hierarchy off, the hierarchy turned off for a custom object, or a restriction rule where the object supports one.
  • Whether confidential data needs its own custom object, so the hierarchy can be turned off for it.
  • Who holds View All, Modify All, View All Data and Modify All Data on that object, starting with the top of the hierarchy.
  • Which other ways of sharing are allowed on it, and who can add them.
  • Whether the company needs a separate org for HR, and why.

Beyond the exam: what AI changes. An agent searches with its user’s access, and the overrides apply to agents too. Give an agent’s user View All on cases, and every confidential case is in its search, whatever branch owns it, and a restriction rule won’t stop it. Keep the override permissions off agent users. Then test each agent the way I test the hierarchy: ask it about the complaint, as the CEO would, and see whether it finds it. Chapter 20 covers agents.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.