Skip to content
SteveTechArcSteveTechArc Courses

Overrides and Implicit Sharing: What You Get for Free

Chapter 10 of Securing Salesforce: Sharing and Visibility, Part 2: The File Cabinets: Sharing Records. New to the course? Start with chapter 1.

Everything in chapters 6 to 9 writes access into the file cabinets: the owner, the hierarchy, rules, teams, territories. This chapter is about the access you get without building any of that.

It starts with the permissions that skip the cabinets altogether. As soon as you check View All, you bypass the share table. Then it turns to what I call the hidden rules: implicit sharing. Nobody writes them. Salesforce grants this access by itself, and you need to know it exists for two reasons: so you can be wary of it, and so you can use it. And it ends with Checkpoint 1, where you build Steve Trucking’s internal model and say what the platform adds on its own.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • Overrides skip the share table. View All and Modify All on one object, View All Data and Modify All Data on every object, and no row anywhere to show it.
  • You find overrides in permissions, not in sharing. The Sharing Overrides list shows profiles; permission sets need a query.
  • Don’t test as the admin. A user with an override can’t show you whether the sharing works.
  • See a child, see the parent. Own an opportunity, contact or case, and you read its account.
  • See the parent, see the children, at the level set on the account owner’s role, for each kind of child.
  • Access goes when the reason goes, and on an account with too many children, finding out is expensive.
  • External users get some for free: their account, the other site users on it, and every case where they’re the contact.
  • Know where it stops: not down an account hierarchy, not on custom objects, and never switched off.

The picture

Section titled “The picture”

Here’s where the chapter starts: the permissions that go around everything you built.

Overrides: four permissions, two sizes Overrides: four permissions, two sizes. On one object: View All Records and Modify All Records, object permissions on a profile or permission set, for users who manage the records of that object. On every object: View All Data and Modify All Data, user permissions for administrators of the whole org, for data cleansing, deduplication, mass deletion and mass transfer. What none of them do: open fields, which still need field permissions or View All Fields; go to external users; write a row in any share table. Footnote: prefer the one object over every object. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-03", "id": "DGM-SVA-OI-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} On one object View All Records, Modify All Records Object permissions On a profile or a permission set For users who manage that object's records The better choice when it's enough On every object View All Data, Modify All Data User permissions Every app and every record For administrators of the whole org Data cleansing, deduplication, mass changes What none of them do the edges Open fields: field permissions still apply Go to external users Write a row in any share table Prefer the one object over every object. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

And the hidden rule that surprises people most: own the account, and its children open.

See the parent, see the children See the parent, see the children, in the same places as the first demo. The same fully Private org and standard user. Step 2: the user is made the owner of the account. Step 3: the account's opportunities, contacts and cases open to the user through child implicit sharing, at the level set on the account owner's role. Footnote: how much the children open is set on the role, for each kind of child (module 3). {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-03", "id": "DGM-SVA-OI-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} A FULLY PRIVATE ORG THE ACCOUNT FAMILY A standard user sees nothing at first The account the user now owns it Its opportunities open, at the role's level Its contacts open, at the role's level Its cases open, at the role's level made the owner implicit child implicit child implicit child How much the children open is set on the account owner's role, for each kind of child. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The path through this chapter

Section titled “The path through this chapter”

Seven modules, each standing on its own.

  1. Overrides: View All, Modify All and the All Data Permissions. Four permissions, two sizes; what they don’t open; their neighbors; finding everyone who holds them; don’t test as the admin; restrict them.
  2. Implicit Sharing: The Six Kinds, and Parent and Child Live. The six kinds; prove the negative first; see a child, see the parent; see the parent, see the children; where it applies.
  3. Child Access on the Role: What Account Owners See. Every role is a sharing decision; different decisions along the branch; when you can’t set it; why no access is a real choice; four places child access is set.
  4. Access Goes When the Reason Goes: What Implicit Sharing Costs. The reason and the check; too many children; child shares that aren’t stored any more; designing so it stays fast.
  5. Site Users and the Case Contact: Implicit Sharing for External Users. A site user’s account and the people on it; the case contact; how far it reaches and how to turn it off; Read and Write means they can edit.
  6. What Implicit Sharing Doesn’t Do: Account Hierarchies and Custom Objects. Account hierarchies don’t share; no implicit sharing on custom objects; no switch; have your implicits in mind.
  7. Checkpoint 1: Steve Trucking’s Internal Users, What I Would Architect. The defaults, the coordinators, a role hierarchy drawn for access, who owns what, the groups, rules and teams, and what the data model shares on its own. Try the challenge first.

Then check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • Who holds View All, Modify All, View All Data and Modify All Data, each with a written reason, reviewed on a schedule, and never used to test sharing.
  • Which of the account’s children are Private, and which are Controlled by Parent, knowing implicit sharing only works for the Private ones.
  • For each role, the access its users get on other users’ contacts, opportunities and cases, including no access where the business means it.
  • Which accounts could grow past 10,000 children, and how the data model keeps them from it.
  • For external users, which account they sit under, and whether case contact access stays on.
  • Where the business assumes access the platform doesn’t give: account hierarchies and custom objects, built on purpose.
  • How it’s tested: an empty, fully Private sandbox and a standard user, proving the negative first.

Beyond the exam: what AI changes. An agent’s user picks up everything in this chapter: an override shows it every record with no row to find, one opportunity opens its account, and an account owner’s role opens the children. So run the override query for agent users first and keep it at zero, list what implicit sharing adds to what an agent’s user owns, and test agents in the same empty, Private setup, proving the negative first. Chapter 20 covers agents.

Explore

Section titled “Explore”

Each module lists its own sources. Two to start with:

Next: Programmatic Sharing: Apex and Flow Managed Sharing

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.