Briefly: implicit sharing is access the platform grants automatically between accounts and their child records, in both directions, without any rule you configured. Read on a child case gives read on the parent account. Owning an account gives access to its contacts, cases and opportunities. None of it appears as a rule anywhere in Setup, and the parent half cannot be switched off.
Parent to child, child to parent
Two distinct behaviours share one name, which is most of the confusion.
- Implicit parent access. A user with access to a Case, Contact or Opportunity gets read access to the Account it hangs off. Read only, on the account record itself, and not on the account’s other children. This is the one you cannot disable.
- Implicit child access. The account owner, and everyone above them in the role hierarchy, gets access to the account’s contacts, cases and opportunities. How much access is controlled by settings on the role.
Both appear in AccountShare with RowCause values of ImplicitParent and ImplicitChild. You can query those rows. You cannot insert, edit or delete them.
SELECT AccountId, UserOrGroupId, AccountAccessLevel, RowCause
FROM AccountShare
WHERE RowCause IN ('ImplicitParent','ImplicitChild')
AND AccountId = '001...'The half you can influence
Implicit child access is shaped by per-object access settings on the role: contact access, opportunity access and case access. Those settings appear only when the corresponding org-wide default is restrictive enough for them to matter, and they can never grant less than the org-wide default already gives everyone.
This is the lever people miss. If account owners are seeing opportunities they should not, the answer is usually the role’s opportunity access setting, not a new sharing rule and not a restriction rule.
Contacts have a further wrinkle. Set the Contact org-wide default to Controlled by Parent and contact access follows account access exactly, which removes the role setting from the picture entirely and is often the simplest correct answer.
The half you cannot
Implicit parent read is not configurable. If a user can see one case, they can see the account name, the account’s fields subject to field-level security, and enough context to identify the customer. Designs that assume account records are invisible to support agents are wrong, and no amount of org-wide default tightening changes that.
Plan for it. Sensitive account attributes belong behind field-level security or on a separate related record, because record-level hiding of the account is not achievable while the user has access to any child.
Where it hurts: volume
Implicit shares are real rows, recalculated by the platform. An account with a very large number of child records generates a very large number of implicit share rows, and every ownership or role change that touches it triggers recalculation of all of them.
This is the mechanism behind account data skew. A single account with tens of thousands of children is not just a reporting annoyance, it is a locking and recalculation problem, and the implicit sharing engine is the reason. The usual fixes are spreading children across more parents, avoiding the catch-all account, and never mass-reassigning ownership of a skewed account during business hours.
Portals and communities
Experience Cloud adds its own implicit behaviour for portal and community users, tying access to the account on the user’s contact. It behaves like the internal model but with a different set of rows and its own recalculation cost. If you have a large community on an account-based data model, expect sharing recalculation to be a recurring operational topic rather than a one-off.
Diagnosing an access surprise
When someone can see a record and nobody can explain why, work through the causes in order: ownership, role hierarchy, sharing rules, teams, territories, manual shares, then implicit. Implicit is last because it is invisible in Setup, and it is frequently the answer. Query the share object with the record Id and read the RowCause column. It tells you which mechanism granted the access in one line, which is faster than any amount of reasoning about the model.
Frequently asked
Can I turn off implicit parent access? No. There is no setting, no permission and no supported workaround. Design around it.
Does implicit parent access give edit rights? No, read only, and only on the account record itself.
Do implicit shares count towards sharing limits? They occupy share table rows and contribute to recalculation time, which is the constraint that actually bites on large orgs.
Why did a role change take hours to apply? Probably implicit share recalculation on accounts with many children. Make role hierarchy changes in a quiet window and expect them to be asynchronous.
