Why This Is Useful
Sooner or later you’ll find a user who can see a Case, Contact or Opportunity that you’re certain nobody granted them access to. You check the sharing rules. Nothing. You check the role hierarchy. Nothing obvious. You check manual shares. Empty.
Nine times out of ten the culprit is child implicit sharing, and it’s controlled somewhere you probably weren’t looking: the role.
What It Actually Does
Go to Setup → Roles and edit any role. Down the page you’ll find three settings:
Contact Access
Opportunity Access
Case Access
These say: if a user in this role owns an Account, what access do they automatically get to the Contacts, Opportunities and Cases hanging off it?
So if the setting is “Users in this role can edit all contacts associated with accounts that they own,” then owning the Account grants edit on every Contact under it. No sharing rule involved. Nothing in the sharing hierarchy that looks like a deliberate grant. It just happens.
That’s implicit sharing, and it flows down the parent-child relationship.
“I Don’t Even See Those Settings”
Then your sharing model is already open, and Salesforce hides settings that couldn’t do anything.
If your org-wide default for Contact is Controlled by Parent, or Case and Opportunity are Public Read/Write, everyone can see everything anyway so there’s nothing to configure.
The settings appear once you tighten your org-wide defaults to Private or Public Read Only. Which is exactly when they start mattering, and exactly when people miss them.
The Mistake Everybody Makes
Somebody spends real effort locking down org-wide defaults, building careful sharing rules, designing a proper role hierarchy… and then creates the roles by clicking through the wizard and accepting whatever the defaults happened to be on those three fields.
Now Account owners can edit every Case under their accounts, which was never the intention and isn’t recorded anywhere that looks like a decision.
So: when you create a role, set those three explicitly. Even if you’re choosing the most restrictive option, choose it deliberately. And if you’ve inherited an org, it’s worth auditing the existing roles, because I’d bet money at least one of them is more generous than anyone realises.
Territory Management Too
If you’re using Enterprise Territory Management rather than roles, the same concept lives in territory settings. Different screen, identical trap.
How To Diagnose It
When somebody has access you can’t explain, don’t start changing settings hopefully. Salesforce will tell you exactly why, and I’ve written up how to instantly tell why a user has access to a record.
Fix the actual cause rather than piling another rule on top of it. Sharing models get impossible to reason about very quickly when people do that.
Salesforce’s Record Level Access architecture guide covers implicit sharing in proper depth if you want the full picture. It’s dry but genuinely worth reading once.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
