The Six Kinds, and Parent and Child Live
Module 2 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: In a fully Private org, why can a user see an account nobody shared with them?
I call implicit sharing the hidden rules. Nobody writes them. Salesforce grants this access by itself, beyond anything we built in chapters 6 to 9, and you need to know it exists for two reasons: so you can be wary of it, and so you can use it.
Salesforce’s definition: “Implicit sharing is a built-in mechanism in the Salesforce platform that automatically grants users access to parent records if they can access related child records and vice versa. There’s also built-in sharing behavior for external site and portal users” (Implicit Sharing (opens in a new tab), Salesforce Help, checked 2026-11-07).
The six kinds
Section titled “The six kinds”There are six kinds, and I teach them by name:
| Kind | What it gives | Who it affects | Where in this course |
|---|---|---|---|
| Parent | Read Only on the account, for a user who can see one of its cases, contacts or opportunities | Internal and external users | This module |
| Child | Access to an account’s cases, contacts and opportunities, for the account’s owner | Internal and external users | This module, and module 3 |
| Site (portal) | The user’s own account, and its contacts who are site users too | External users | Module 5 |
| Case contact | Read and Write on a case where the site user is the contact | External users | Module 5 |
| High volume | Full access to records owned by high-volume site users, for members of a sharing set’s share group | Internal users in the share group | Chapter 15 |
| High-volume parent | Read Only on the parent account of those records, for the same members | Internal users in the share group | Chapter 15 |
The first four are pretty straightforward. The last two are a little more obscure, and they only make sense once you know sharing sets, so they wait for chapter 15.
Salesforce’s own table lists the same ground in five rows: parent, child, Experience Cloud site, high volume and high-volume parent. Its site row covers both the account and contacts and the case contact (Implicit Sharing (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition, checked 2026-11-07). I keep the case contact on its own, because it’s the one I see people miss.
Salesforce also says which ones matter most: “two that affect internal and external users, and a few more that only affect external users” (Implicit Sharing, Salesforce Help). The two are parent and child. Here they are, live.
The setup: prove the negative first
Section titled “The setup: prove the negative first”To see implicit sharing, you have to remove everything else. So I start with a brand-new sandbox:
- In Sharing Settings, the account, contact, opportunity and case all set to Private. Not Controlled by Parent: Private.
- No sharing rules of any kind. Check: the lists are blank.
- A standard user, not an admin. Log in as them: no accounts, no opportunities. Access to nothing.
That last check matters. It’s the habit from chapter 1: prove the negative before you prove the positive. If the user could already see something, you wouldn’t know what the test showed.
Demo 1: see a child, see the parent
Section titled “Demo 1: see a child, see the parent”Take one opportunity, and change its owner to that standard user. The user now sees the opportunity, of course. They own it.
Now go to all accounts. The opportunity’s account is there.
The user doesn’t own the account. No sharing rule gives it to them. The only reason they can see it is implicit sharing. Salesforce’s words: “If you have access to an account’s child case, contact, or opportunity record, you have implicit Read Only access to that account, even with org-wide defaults on Account set to Private” (Implicit Sharing, Salesforce Help).
When I do this in class, I ask the room: account is Private, opportunity is Private, I only shared the opportunity. Why is the account visible? And here’s the reason it works that way. An opportunity has to have an account. If you saw the opportunity without its account, you’d be seeing a child without its parent. So Salesforce gives you the parent, Read Only.
Now take it away. Change the opportunity’s owner back. Refresh the accounts. The account is gone. The access lasted exactly as long as its reason did. Module 4 looks at what that costs Salesforce.
Test knowledge. Know why a user who was given only an opportunity, a contact or a case can read its account, with every default Private: parent implicit sharing, Read Only. Know its conditions: the child must be seen through ownership or sharing, not through View All, and it doesn’t apply when the child is Controlled by Parent. It’s a classic question in class and on the architect journey. A likely area, not a known question.
Demo 2: see the parent, see the children
Section titled “Demo 2: see the parent, see the children”Same empty org. This time, take an account, and change its owner to the user.
The user sees the account. In a fully Private model, that should be all they see. But go to all opportunities, and the account’s opportunities are there. Go to contacts, and its contacts are there too.
That’s child implicit sharing: “if you have access to a parent account, you can have access to the associated child case, contact, and opportunity records.” How much is set by the account owner’s role, and by the account’s sharing rules and manual shares (Implicit Sharing, Salesforce Help).
Notice the words “can have” and “the account owner’s role.” How much the children open, nothing, view or edit, is set on each role, for contacts, opportunities and cases separately. Module 3 covers that setting. And Salesforce’s table adds that child implicit sharing “Supports account sharing rules that grant child record access” and “account team access based on team settings,” and that “When a user loses access to the parent, Salesforce removes the user’s access to all children records” (Designing Record Access for Enterprise Scale).
So the short version, as I say it in class: under a Private model, if you see the parent, you see the children. If you see a child, you see the parent.
Where it applies, and where it doesn’t
Section titled “Where it applies, and where it doesn’t”Implicit sharing isn’t everywhere. It applies only to these special account children.
- The account and its cases, contacts and opportunities. That’s the family both demos used. “Built-in sharing behaviors apply only to standard relationships” (Implicit Sharing, Salesforce Help). Custom objects don’t get it, which is module 6.
- Only when the child is Private. Parent implicit sharing is “Not used when sharing on the child is controlled by its parent,” and so is child implicit sharing (Designing Record Access for Enterprise Scale). If the child is Controlled by Parent, you see the children because you see the account anyway. Implicit sharing kicks in when you mark them Private.
- Not through View All. “You can’t access the parent account if you only have access to the child records through the View All Records or Modify All Records object permissions” (Implicit Sharing, Salesforce Help), and child implicit is “Not granted by the View All permission on the parent object” (Designing Record Access for Enterprise Scale). Module 1 showed that View All on accounts doesn’t open the standard children either. Implicit sharing follows real ownership and real shares, not overrides.
Two more account children have built-in sharing of their own, and they behave differently (Implicit Sharing, Salesforce Help):
- Orders. If you own an order, or you’re above its owner in the role hierarchy, you get Read Only on its account. But if the order was shared with you by a rule or by hand, “you can only see the related parent account’s name.” And the other direction doesn’t work: “If you have access to a parent account, you don’t automatically have access to its child orders.”
- Contracts. Contracts don’t have a default of their own: “Account and contract access is configured by using the same organization-wide default setting.” See a contract, and you read its account. See the account, and you see its contracts.
Where it shows up
Section titled “Where it shows up”Parent implicit access writes a row: on AccountShare, the row cause is ImplicitParent (chapter 5, module 5). Child implicit access no longer does: not for cases and contacts since Summer ‘23, and not for opportunities since Winter ‘24. Salesforce works it out when the user opens the record. Module 4 covers those changes.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video of implicit sharing in a brand-new org: an opportunity’s owner gaining the account, and an account’s owner gaining its children. The note under the video says what’s still right and what’s changed since.
What an architect decides here
Section titled “What an architect decides here”- Which of the account’s children are Private, and which are Controlled by Parent, knowing implicit sharing only works for the Private ones.
- What users will see through the children they own: every opportunity owner reads its account.
- What account owners will see on the children, set role by role (module 3).
- Whether orders and contracts behave the way the business expects, since their built-in sharing differs from cases, contacts and opportunities.
- How the team tests it: an empty, fully Private sandbox and a standard user, proving the negative first.
As you design your sharing rule patterns, have your implicits in mind. Salesforce will be granting this access, so understand it and anticipate it.
Beyond the exam: what AI changes. An agent’s user picks up implicit access like any other user: give it one opportunity, and it can read the account, and say what it read. When you plan what an agent may see, list the children its user owns or is shared, then add their accounts. And when you test an agent, use the same empty, fully Private setup and prove the negative first. Chapter 20 covers agents.
Explore
Section titled “Explore”- Implicit Sharing (opens in a new tab), Salesforce Help (checked 2026-11-07)
- Implicit Sharing (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition (checked 2026-11-07)