What Implicit Sharing Costs

Module 4 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: When implicit access goes away, what does Salesforce have to do, and when does that get expensive?

In module 2’s demo, I changed an opportunity’s owner back, refreshed, and the account was gone. Read Only access was granted to the parent when the user had access to the child, and when they lost access, Salesforce removed it. It looks instant. Behind it is work, and on the wrong data model, a lot of it.

The reason, and the check

Implicit access lasts exactly as long as its reason. Salesforce’s table says so for both directions (Implicit Sharing (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition, checked 2026-11-07):

Parent implicit: “When a user loses access to a child, Salesforce must check all other children to see if it can delete the implicit parent.”
Child implicit: “When a user loses access to the parent, Salesforce removes the user’s access to all children records.”

The second one is simple. The parent was the reason, the parent’s gone, the children go.

The first one isn’t. A user can see the account through any of its children. Lose one opportunity, and they may still have another, or a contact, or a case. So before Salesforce can take the account away, it has to look at every other child of that account and confirm the user can’t see any of them. Same table, same row: parent implicit sharing is “Expensive to maintain with many account children.”

That’s what I mean in class when I say it can be expensive with many children. When a user loses access to a child, Salesforce checks all the children, and then it decides.

When the account has too many children

Salesforce calls it parent-child data skew: “the association of a large number of child records (10,000 or more) with a single parent account” (Parent-Child Data Skew (opens in a new tab), Designing Record Access for Enterprise Scale, Winter ‘27 edition, checked 2026-11-07).

How does an org get there? Salesforce gives the usual story. Marketing brings in thousands of contacts with no real business account. A contact needs an account, so someone parks them all under one placeholder account until they’re sorted out. It seems reasonable. It “can cause serious performance problems in the maintenance of implicit sharing” (same page).

Salesforce’s numbers: 300,000 contacts under one account. A user who can see one contact has a parent implicit share on that account. Take that one contact away, and “Salesforce must scan all of the other 299,999 contacts to ensure that the user doesn’t have access to them either” (same page). Once is fine. Many visibility changes on accounts like that, and it gets expensive.

Click to enlarge

What Salesforce changed: child shares aren’t stored any more

Salesforce attacked the other half of the cost. Child implicit access used to be stored as share rows between each account and its children, and every recalculation of account sharing had to keep those rows up to date.

In Summer ‘23, Salesforce stopped doing that for cases and contacts: “We no longer store implicit child share records between accounts and their child case and contact records. Instead, the system determines whether users can access child case and contact records when they try to access them.” It was enforced in existing production orgs in Winter ‘24, and the reason is speed: “Not storing these implicit child share records speeds up ownership and sharing rule recalculation for accounts” (Enable Faster Account Sharing Recalculation by Not Storing Case and Contact Implicit Child Shares (opens in a new tab), Summer ‘23 release notes, checked 2026-11-07).

Opportunities followed. “Implicit child share records are no longer stored between accounts and their child opportunity records. Instead, the system determines whether users can access child opportunity records when they try to access them.” That update “was first available starting in Winter ‘24 and is enforced in Spring ‘24” (Release Updates (opens in a new tab), Spring ‘24 release notes, checked 2026-11-07).

Two things to know from the Summer ‘23 note:

Queries and tests that read those rows find nothing. “SOQL queries or Apex tests that query implicit child case and contact share records no longer return any results because Salesforce no longer stores these records.” If old code or an old test counted those rows, it’s wrong now. Test what the user can see, not what rows exist.
One side effect for sites. After the update, “account owners can gain access to cases and contacts owned by high-volume Experience Cloud site users, depending on the org’s role hierarchy configuration.” Chapter 15 covers high-volume users.

The parent direction is still a row. A user who sees an account through a child still has a row on AccountShare with the row cause ImplicitParent (chapter 5, module 5). That’s the row the check above decides whether to delete.

Click to enlarge

Designing so it stays fast

Salesforce’s guidance after these pages is short, and every line is a design decision (Takeaway: Tuning Data Relationships and Updates for Performance (opens in a new tab), Designing Record Access for Enterprise Scale, Winter ‘27 edition, checked 2026-11-07):

“Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data.” If nobody needs it hidden, don’t pay to hide it.
“To avoid creating parent implicit shares, configure child objects to be Controlled by Parent wherever this configuration meets security requirements.” Module 2 showed why: implicit sharing only works for Private children.
“Configure parent-child relationships with no more than 10,000 children to one parent record.” No placeholder account for everything that doesn’t fit.
Test big loads and relationship changes “in a full copy sandbox that’s been recently refreshed so you know what to expect.”

None of this means don’t use implicit sharing. It’s a good tool to have, and I want you to use it. It means know it’s there, be wary of it, and keep the data model it runs on healthy. Chapter 22 takes on sharing at scale: locking, bulk loads and large realignments.

What an architect decides here

Which accounts could grow past 10,000 children, and how the data model keeps them from it, including where unallocated contacts go instead of one placeholder account.
Which children are Controlled by Parent, to avoid parent implicit shares, and which must stay Private, knowing what that costs.
Which objects can be Public Read Only or Public Read/Write, because nothing in them is confidential.
That no code, test or report depends on implicit child share rows for cases, contacts or opportunities.
How large loads and ownership changes on big accounts are tested first, in a recently refreshed full copy sandbox.

Beyond the exam: what AI changes. Agents and automations can change ownership and sharing far faster than people do, and every change on a heavily loaded account sets off this check. Before an agent or a flow is allowed to reassign records in bulk, find your skewed accounts, and test the change at that volume. And when an AI assistant writes a test for your sharing, make sure it checks what the user can see, not whether implicit share rows exist. Chapter 20 covers agents.

Explore

Implicit Sharing (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition (checked 2026-11-07)
Parent-Child Data Skew (opens in a new tab), Designing Record Access for Enterprise Scale, Winter ‘27 edition (checked 2026-11-07)
Takeaway: Tuning Data Relationships and Updates for Performance (opens in a new tab), Designing Record Access for Enterprise Scale, Winter ‘27 edition (checked 2026-11-07)
Enable Faster Account Sharing Recalculation by Not Storing Case and Contact Implicit Child Shares (opens in a new tab), Summer ‘23 release notes (checked 2026-11-07)
Release Updates (opens in a new tab), Spring ‘24 release notes (checked 2026-11-07)