View All, Implicit, Data Categories

Module 5 of 9 in the chapter Steve’s 25 Ways to Share a Record: The Map, chapter 5 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Which records does Salesforce open by itself, with no rule, no team and no code, and how do you find out it did?

Sets 1 to 3 are things someone sets up. Set 4 is Salesforce itself: the permissions that see every record, the access the platform gives you between parents and children, and a model of its own for Knowledge. Three ways: View All and Modify All, implicit sharing, and data category visibility.

I call implicit sharing the hidden rules. They’re not overt. You need to know they exist for two reasons: so you can be wary of them, and so you can use them.

Click to enlarge

Way 13: View All and Modify All

Profiles and permission sets can give View All or Modify All on an object. These override all the sharing. A user who has View All on an object sees every record of it, top to bottom. There is no way to hide a record from them. Modify All does the same for edit. Salesforce’s words: the View All and Modify All permissions “ignore sharing rules and settings” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-01).

Their bigger siblings work on every object at once. View All Data and Modify All Data are user permissions, “not an object-level permission like View All Records” (Factors that Affect Data Access (opens in a new tab), Object Reference, checked 2026-11-01).

This is the one time the office overrides the file cabinet, as chapter 4, module 1 covered. So really watch the use of View All and Modify All. Restrict them to your system admins and the few people with a written reason. Don’t make them a common tool in your toolbox.

My deck had a note beside this card: delegated administration. It’s worth saying why it isn’t a way of its own. A delegated admin can manage users in certain roles, assign permission sets and manage public group membership. That changes who’s in the groups and roles that rules share with, but it doesn’t open a record by itself. Salesforce says so: “To delegate administration of particular objects, use object permissions, such as ‘View All Records’ and ‘Modify All Records,’ instead” (Delegate Administrative Duties (opens in a new tab), Salesforce Help, checked 2026-11-01). So a delegated admin is someone to watch, not a way to share.

Way 14: implicit sharing

Salesforce: “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.” And “Built-in sharing behaviors apply only to standard relationships” (Implicit Sharing (opens in a new tab), Salesforce Help, checked 2026-11-01).

Child to parent: see a child, read its account

“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).

Here’s my demo. A fresh sandbox, the account, contact, opportunity and case all set to Private. A standard user who can see nothing: no accounts, no opportunities. I take one opportunity and change its owner to that user. Now go to all accounts, and the opportunity’s account is there. The user doesn’t own it, and no sharing rule gives it to them. The only reason they can see it is implicit sharing. Change the opportunity’s owner back, and the account is gone again.

One catch from the same page: it only counts if you see the child by ownership or sharing. “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.”

Parent to child: see an account, see its children

The other direction: with access to a parent account, “you can have access to the associated child case, contact, and opportunity records.” How much is decided by “The account owner’s role and settings configured in account sharing rules and manual shares” (Implicit Sharing).

In the demo, I give the same user an account. Now they see its opportunities and its contacts too. How much they get is set on the role: on each role, you choose whether users in it can see, or edit, the contacts, opportunities and cases on accounts they own. Different branches of the hierarchy can get different answers.

And watch where this applies. It’s for a Private child, not one that’s Controlled by Parent. If it’s Controlled by Parent, you see the children because you see the account anyway. Implicit sharing kicks in when you mark the children Private.

Site and portal users

The rest affect external users. An account’s site or portal user “has access to the parent account and to all of the account’s contacts that are enabled as partner or customer users” (Implicit Sharing). So a site user can see the other site users at their company. Watch for that.

And the case contact, which I think is a really important one. A question I ask in class: a customer creates a case on your site. They want to see its status afterwards. How do they? A sharing set would show them all their account’s cases, not that one case. When they create it, they’re the owner for a moment, but as soon as case assignment rules run, they aren’t. Salesforce has a built-in answer: “If a portal or site user is a contact on a case, then the user has Read and Write access on the case” (Implicit Sharing).

The cost

Implicit sharing isn’t free. It can be expensive with many children: when a user loses access to a child, Salesforce has to check whether they still have a reason to see the parent. Chapter 10 goes into the cost, and what happens on accounts with very many children.

Way 15: data category visibility

This is the one way on the map that’s only for one family of records: Knowledge articles and questions. Salesforce: “Category group visibility settings determine who can access articles and questions. Although they are standard objects, articles and questions do not have organization-wide defaults, sharing rules, or manual record sharing” (How Category Visibility Differs from Other Salesforce Models (opens in a new tab), Salesforce Help, checked 2026-11-01).

So none of Sets 1 to 3 applies to them. Instead, articles and questions are tagged with data categories, and users are given visibility to categories through their role, a permission set or their profile. A child role can’t see more categories than its parent (same page).

If your org has Knowledge, this is the way that decides which articles a user, a site visitor or an agent can find. Chapter 12 covers it with the other data.

The share table: what Set 4 writes, and doesn’t

Set 4 is the first set where the share table doesn’t tell the whole story.

• View All and Modify All write no row. As soon as you give View All, the user bypasses the share table. You’ll never find their access by querying it. You find it in their profile and permission sets.
• Child to parent writes a row. On AccountShare, a user who sees an account through a child has a row with the row cause ImplicitParent (AccountShare (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-01).
• Parent to child, for cases and contacts, no longer does. Since Summer ‘23, “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.” Salesforce enforced it in existing production orgs in Winter ‘24, and “SOQL queries or Apex tests that query implicit child case and contact share records no longer return any results” (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-01).
• Data categories aren’t in a share table at all. They’re a model of their own.

So when someone asks how a user can see a record, the share table is the first place to look, not the last.

Click to enlarge

Where this goes deep

Chapter 10, Overrides and Implicit Sharing: What You Get for Free, takes these apart: who holds View All and why, every kind of implicit sharing, and what it costs at scale. Data category visibility is in chapter 12. The implicit sharing that comes with sharing sets for high-volume site users is in set 7, module 8. For now, have your implicits in mind when you design.

What an architect decides here

• Who holds View All, Modify All, View All Data and Modify All Data, each with a written reason.
• Who the delegated admins are, and which groups and roles they can change.
• For each role, how much its users get on the children of accounts they own.
• Which objects are Private and which are Controlled by Parent, knowing implicit sharing only applies to the Private ones.
• What site users will see through their account and their cases.
• If the org has Knowledge, the data categories and who sees each one.

Beyond the exam: what AI changes. An agent’s user picks up implicit access like anyone else: give it one opportunity and it can read the account. And never give an agent’s user View All Data to make it work. That’s every record in the org, with no row in any share table to show it. If an agent can’t find what it needs, fix its sharing, not its permissions. Chapter 20 covers agents.

Explore

• Implicit Sharing (opens in a new tab), Salesforce Help (checked 2026-11-01)
• 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-01)
• How Category Visibility Differs from Other Salesforce Models (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Delegate Administrative Duties (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Factors that Affect Data Access (opens in a new tab), Object Reference (checked 2026-11-01)
• AccountShare (opens in a new tab), Object Reference (checked 2026-11-01)
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-01)