Account Hierarchies and Custom Objects

Module 6 of 6 in the chapter Overrides and Implicit Sharing: What You Get for Free, chapter 10 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Where do people expect Salesforce to share by itself, when it doesn’t?

Modules 2 to 5 were about what you get for free. This one is about what you don’t. Once people learn that seeing an opportunity shows them its account, they start to assume the platform shares along every relationship. It doesn’t. In class, a student asked me whether this was simply part of going Private. Yes, I said, implicit parent sharing comes with Private. But only for these limited objects: the account’s children, and not even all the standard objects, just these special account children.

Three limits follow from that, and each one is a design decision.

Salesforce’s architects are blunt about this one: “A lot of people make a bad assumption when they implement an account hierarchy. They assume the users who can access a parent account can also access the children accounts.” A parent and child relationship between two records doesn’t give access by itself: the role hierarchy and the territory hierarchy work that way, but the account hierarchy doesn’t (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07).

Picture a global company in your org: one parent account, and under it a subsidiary in each country, each its own account with Parent Account filled in. A global account manager owns the parent. With accounts Private, what do they see?

The parent account, because they own it. Its contacts, opportunities and cases, as far as their role allows (module 3). And none of the subsidiaries. Parent Account is a lookup from one account to another, and an account isn’t one of the special children. The subsidiaries are owned by the people in each country, and nothing about the hierarchy opens them upward or downward.

Click to enlarge

If the business does want the global account manager to see the whole family, you have to build it, with tools from earlier chapters:

Territories. An account can sit in more than one territory, so the whole family can sit in one key account territory too (chapter 9, modules 3 and 4).
Account teams. Add the global account manager to each subsidiary’s team (chapter 9, module 2).
A criteria-based rule on a field. Mark every account in the family, for example with the top parent’s name in a text field kept up to date by automation, and share on that field. Criteria can’t read a formula field, so it has to be a real field (chapter 7, module 2).
Programmatic sharing. Code or a flow that walks the hierarchy and writes shares (chapter 11).

Each has its own cost when the hierarchy changes. Decide which one before someone assumes the hierarchy already does it.

The second limit, in one line from the same guide: “Implicit sharing doesn’t apply to custom objects” (Platform Sharing Architecture). Salesforce Help says it the other way round: “Built-in sharing behaviors apply only to standard relationships” (Implicit Sharing (opens in a new tab), Salesforce Help, checked 2026-11-07).

So say you build a custom object for an account’s service contracts, Private, with a lookup to Account. Own a service contract, and you don’t get to read its account. Own the account, and you don’t see its service contracts. Module 2’s demos don’t work here at all.

If you want the custom child to follow its parent, design it in:

Master-detail, Controlled by Parent. The detail’s access follows the parent record (chapter 6, module 6). See the account, see its contracts. That’s a choice you make when you design the object, and it’s hard to change later.
Sharing of its own. If the child must be Private with its own owner, give it its own sharing: rules or code (chapters 7, 8 and 11). Teams won’t help, since they’re only for accounts, opportunities and cases (chapter 9, module 2).

There’s one place a parent opens custom children, and it’s an override, not implicit sharing: View All Records on an object “does give access to its child custom object records without access being granted via sharing” (module 1).

You can’t switch it on or off

The third limit: “Implicit sharing is automatic. You can neither turn it off, nor turn it on—it is native to the application” (Platform Sharing Architecture). There’s no checkbox for parent or child implicit sharing.

What you can do is design around it:

Make the child Controlled by Parent, and parent implicit shares aren’t created at all (module 4).
Set the role’s child access to no access, where account owners mustn’t see other people’s records (module 3).
Turn off the case contact behavior for site users, the one built-in kind with its own setting, Grant site users access to related cases (module 5).

Click to enlarge

Have your implicits in mind

That’s the chapter. Salesforce opens records by itself in more places than most people know: the overrides in module 1, the six kinds in module 2, the role’s setting in module 3, and the site and case contact in module 5. And it doesn’t open them in places where people assume it does: account hierarchies and custom objects.

So as you design your sharing rule patterns, have your implicits in mind. Know the parent to child, the child to parent, and the case contact. Understand that Salesforce will be granting this access, so you can understand and anticipate it, and know where it won’t, so nobody assumes it.

What an architect decides here

Whether anyone should see a whole account hierarchy, and which way builds it: territories, teams, a rule on a field, or code.
For each custom child of an account: master-detail and Controlled by Parent, or Private with sharing of its own.
Which children are Controlled by Parent, to avoid implicit shares where security allows.
Where the business assumes access that the platform doesn’t give, written down before go-live.

Beyond the exam: what AI changes. When someone asks an agent “show me everything for this customer,” they usually mean the whole account hierarchy and every custom object about it. The agent can only show what its user can see, and implicit sharing won’t fill those gaps. So when you scope an agent’s job, check that the access it needs across the hierarchy and the custom objects is actually built, and test it with a real user. Chapter 20 covers agents.

Explore

Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-07): sections Implicit Sharing, and Account Hierarchies’ Impact on Data Access
Implicit Sharing (opens in a new tab), Salesforce Help (checked 2026-11-07)