How Salesforce Decides Who Can See a Record

Module 1 of 7 in the chapter Org-Wide Defaults, Ownership and the Role Hierarchy, chapter 6 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When a user opens a record, runs a report or searches, how does Salesforce decide which records they can see, and why does that matter for your design?

Part 1 got you into the building and into the offices. Now Part 2 opens the file cabinets for real. You’ve made it into the building, you’ve made it into the HR office, and now there are these locked file cabinets. Just because you made it into the office doesn’t mean you see every file.

Chapter 5 gave you the map: 25 ways, in eight sets. Before we take Set 1 apart in this chapter, let’s look under the hood at how Salesforce actually answers the question “can this user see this record?” Once you see how it works, a lot of the design advice in the rest of this course stops being rules to memorize. It just makes sense.

Two rules, at two different lines

There are two rules, and people mix them up.

Between the office and the cabinet, the most restrictive wins. Chapter 1 taught this one. If you have Edit on the object and the record is shared with you as Read Only, you get Read. And the other way round: Read on the object and a Read/Write share gives you Read. It’s not when you start layering where it’s additive. View All and Modify All are the one time the office overrides the cabinet.

Inside the cabinet, the most generous reason wins. A user can have many reasons to see the same record: they own it, a rule shares it with their group, they’re on its team, someone shared it with them by hand. Salesforce doesn’t add these up, and it doesn’t pick the first one. It takes the best one. In Salesforce’s words: “For users with multiple access grants to a record, Salesforce uses the most permissive grant when determining record access” (Sharing Rows (opens in a new tab), Record-Level Access: Under the Hood, Salesforce Developers, checked 2026-11-07).

So one rule takes the lowest, and the other takes the highest. Keep them on their own lines and you’ll answer most “why can she see this?” questions in your head.

It also tells you something about design. Inside the cabinet, every way you add can only open records up. Adding a rule never takes access away from anyone. That’s why chapter 5 put taking access away in a set of its own, Set 6.

Four kinds of access grant

Salesforce calls each reason an access grant. When an object’s default is Private or Public Read Only, it uses grants to decide “how much access a user or group has to that object’s records.” There are four kinds: “explicit grants, group membership grants, inherited grants, and implicit grants” (Access Grants (opens in a new tab), Record-Level Access: Under the Hood, checked 2026-11-07).

• Explicit grants give one record to one user or group directly. A user or a queue becomes the owner. A sharing rule, a territory assignment rule, a team, a manual share or code shares the record. On the map, that’s ownership and queues, the sharing rules, manual shares, teams, territories and programmatic sharing.
• Group membership grants come from being in a group that has the access. A rule shares a record with a group, you’re in the group, so you see the record.
• Inherited grants come from a hierarchy. The record is shared with someone below you in the role or territory hierarchy, so you see it too. That’s way 2, grant access using hierarchies.
• Implicit grants are the ones Salesforce builds in: see a child opportunity, case or contact and you can read its account, and the other way round. That’s way 14, and it’s chapter 10.

Click to enlarge

Where Salesforce keeps the answer: three kinds of table

Here’s where it gets interesting. Some people don’t realize there are share tables at all. Salesforce keeps access in three kinds of table (Database Architecture (opens in a new tab), Record-Level Access: Under the Hood, checked 2026-11-07):

• The object’s own table holds the records, and it says who owns each one.
• The object’s sharing table, the share table, holds the grants: one row per grant, each with the record, the user or group, the access level, and the row cause, the reason. Chapter 5 showed you AccountShare. Salesforce says each row records “the type of sharing tool — sharing rule, team, etc. — used to provide that access” (Access Grants).
• The group maintenance tables hold who belongs to which group. Not only your public groups: Salesforce makes its own groups behind the scenes for queues, and for every role and territory. For each role it keeps groups such as Role and RoleAndSubordinates, so it already knows who sits above whom (Group Maintenance Tables (opens in a new tab), Record-Level Access: Under the Hood, checked 2026-11-07).

When you open a record, Salesforce joins the three. The record table to the sharing table on the record ID, and the sharing table to the group tables on the user or group ID. If a row in either one grants you access, you see the record (Database Architecture).

Click to enlarge

And not every object gets a share table. Salesforce lists three cases where it doesn’t (Database Architecture):

• the detail in a master-detail relationship: the master’s share table decides,
• an object whose internal and external defaults are both Public Read/Write: there’s nothing to grant,
• objects with “their own access control mechanism,” such as activities and files.

That’s why I say some mechanisms are in the share table and some are not. A share table is where the explicit grants live. The hierarchy lives in the group tables. And the rest, like View All, never write a row at all.

Worked out in advance, not when you look

This is the part I want every architect to hold on to. Salesforce doesn’t work out your access when you open the record. It can’t: a big org has hundreds of roles, thousands of rules and millions of rows, and working through them all every time would take “far more time than the 300-millisecond Salesforce benchmark for rendering pages.” So “Salesforce calculates record access data only when configuration changes occur” (Record Access Calculation (opens in a new tab), Record-Level Access: Under the Hood, checked 2026-11-07). The answer is written down ahead of time, in those tables.

That’s what makes the read fast. It’s also what makes some changes slow. Change a rule, move a role, change an owner, and Salesforce has to rewrite the answer for everyone it touches.

Salesforce’s own example is moving one user to another branch of the role hierarchy. The managers above the old role lose access to everything that user owns. The managers above the new role gain it. Every sharing rule with the old or new role as its source is recalculated. And if the user owns customer or partner accounts, their roles move too. Salesforce’s comment: “a lot can happen under the hood when an administrator takes what looks like a simple action, such as changing the role of a user” (Group Membership Operations and Sharing Recalculation (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, checked 2026-11-07).

Remember what I said about the owner low in the hierarchy with many people above them: that’s a lot of sharing cascaded upwards. Now you know where it’s cascaded to. It’s in the group tables, worked out in advance, and recalculated every time that branch changes.

What this means for your design

Three habits come straight out of how it works.

Share with a bucket, not a person. If you have a hundred people who need access, why create a hundred share records? If it’s a common grouping, I call it a bucket. Have one share record to the bucket, and then just add and remove people from the bucket. Salesforce says the same: granting access to a group “saves time and results in fewer sharing rows” (Sharing Rows). Chapter 7 is all about the buckets.

Every hierarchy is a cost as well as a tool. “The size and complexity of an organization’s queues and hierarchies directly affect the duration of record access calculations” (Group Maintenance Tables). A deep role hierarchy, built as an org chart, makes every move expensive. Module 4 designs the hierarchy for access instead.

Know where to look. When someone asks why a user can see a record, the answer is a grant, and most grants are rows. Query the share table in Workbench or any tool that runs SOQL, read the row causes, and check which groups the user is in. Chapter 13 makes this a habit.

What an architect decides here

• That the team can explain both rules: the most restrictive between the office and the cabinet, the most generous inside the cabinet.
• For each requirement, which kind of grant will meet it: explicit, group membership, inherited or built in.
• Which access goes to groups rather than to people, to keep share rows few and changes cheap.
• Which changes are expensive (moving roles, changing owners of many records, changing rules) and when they run, before a big change goes live.
• Who can read the share table and the group memberships to explain an access question.

Beyond the exam: what AI changes. An agent reads through the same tables as everyone else: its user’s grants decide what it finds, in a search or a query, in milliseconds. That’s the point of calculating access in advance. So when an agent’s user is added to a group or a role, every record that group or role can see is already open to the agent, at that moment. Add agent users to buckets on purpose, and check what each bucket opens. Chapter 20 covers agents.

Explore

• Record-Level Access: Under the Hood (opens in a new tab), Salesforce Developers (checked 2026-11-07): Record Access Calculation (opens in a new tab), Access Grants (opens in a new tab), Database Architecture (opens in a new tab), Sharing Rows (opens in a new tab) and Group Maintenance Tables (opens in a new tab)
• Group Membership Operations and Sharing Recalculation (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers (checked 2026-11-07)