Who Can See It, and Why

Module 4 of 6 in the chapter Testing the Security Model, chapter 13 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: A test tells you a user can see a record. What tells you why, and what can you show someone else?

Modules 1 to 3 proved access by trying it: log in as the user, run as the user. That answers “can they?” An auditor, a security team or the next architect will ask the next question: why can they? And they’ll want to see it for themselves.

In class, while I share a record, I keep the share table open in Workbench. Twenty-six shares on the account object. I share one record, run the query again, and it’s twenty-seven, with a Manual share right there. I delete the share, and it’s back to twenty-six. I’m just giving you the habits I use to validate. The test shows what the user sees. The evidence shows why.

Four questions, four places to look

Every piece of evidence answers one of four questions. Each has its own tool, and each tool has something it doesn’t show.

Click to enlarge

What can this user do?

Start with the user. On the user’s detail page in Setup, View Summary opens the User Access Summary, which I introduced in chapter 3. Salesforce’s troubleshooting steps start here: “In the Object Permissions tab, you can see all of the user’s assigned object permissions.” And when a permission is there that shouldn’t be, “click the permission’s row-level action, and then click Access Granted By,” which shows the profile, permission sets or permission set groups granting it (Troubleshoot Object and Record Access Issues (opens in a new tab), Salesforce Help, checked 2026-11-07).

That’s the evidence for module 2’s first layer: which block a permission came from. And it’s the first thing to rule out, because a user with View All Records on the object, or View All Data, sees every record “regardless of the sharing settings” (same page). No amount of sharing evidence explains that.

What it doesn’t show: records. The summary tells you what the user can do with an object. It doesn’t tell you which records they can see.

Who can see this record, and why?

Now the record. In Lightning Experience, “click Sharing Hierarchy from the Action Menu on the desired record.” It lists the users with access, and “To see the reason the user has or doesn’t have access to the record, click View next to a user’s name” (Viewing Which Users Have Access to Your Records in Lightning Experience (opens in a new tab), Salesforce Help, checked 2026-11-07). In Classic, it’s the Sharing button and Expand List.

The reasons are the course’s ways to share, in Salesforce’s words: Owner, Account Sharing Rule, Manual Sharing, Account Team, Account Territory, Group Member, Associated Record Owner or Sharing, Portal Share Group, and more. And “Administrator”: the user “has the ‘Modify All Data’ or ‘View All Data’ administrative permission, or the ‘Modify All Records’ or ‘View All Records’ object permission” (same page). This is the best single piece of evidence for module 1’s three users: the user who should see the record is on the list with the reason you designed, and the user who shouldn’t isn’t there.

Three limits, all from the same page:

• Only access above the default. The list “shows every user who has access that’s greater than the org-wide default settings.” If the object is Public Read Only, everyone can read it and nobody’s listed for that.
• Restriction rules. “In editions that support restriction rules, this list can include users who don’t have access due to a restriction rule.” Click View: “If a restriction rule blocks access to the record, a message is shown to confirm that access is blocked.”
• Some reasons are merged. “If multiple sharing reasons give a user access to a record, some sharing reasons can be compressed into a single reason, which shows the most permissive access level.” Owner and Manual Sharing are among them, so a reason can hide another one behind it.

If you don’t see Sharing Hierarchy at all, “make sure it’s added to the page layout” (same page).

Can this user see these records?

The Sharing Hierarchy is one record at a time. For a test plan with many records, ask the question in a query. UserRecordAccess “Represents a user’s access to a set of records,” with fields for read, edit, delete, transfer and share, and MaxAccessLevel, from None to All (UserRecordAccess (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-07). Salesforce’s sample, in its shape:

SELECT RecordId, HasReadAccess, HasEditAccess, MaxAccessLevel
FROM UserRecordAccess
WHERE UserId = '<the user>'
AND RecordId IN ('<record>', '<record>')

That’s module 2’s table, answered in one query: for this persona, these records, read or not, edit or not. “Up to 200 record IDs can be queried” (same page).

Two catches, both on the same page, and both matter for evidence:

• It ignores restriction rules. “UserRecordAccess doesn’t consider whether a user’s access is blocked due to a restriction rule.” A true here can still be a record the user can’t open.
• It sees through your eyes first. “When the running user is querying a user’s access to a set of records, records that the running user doesn’t have read access to are filtered out of the results.” Run it as someone who can see every record you’re asking about.

Which rows exist, and why?

Then the share table, the way I watch it in class. Each row has the record, the user or group, the access level and the row cause. Chapter 6 showed you where to look, and chapter 5 listed what the share table doesn’t show: the org-wide default, the role hierarchy, View All and system mode, child access to cases and contacts, sharing sets, restriction rules and data categories.

So the share table is the evidence for the rows your design writes: rules, manual shares, teams, territories, your code’s own reason. A row with your reason, for the right group, is proof your code did its job. No row doesn’t prove no access.

Where is this group used?

One more, because so much sharing goes through groups. Since Summer ‘24, a group has its own summary: “For a specific public group, you can view the sharing rules an object is referenced in and the list views it’s shared with in the new Public Group Access Summary.” It also shows the report and dashboard folders the group can open, and the other public groups it’s in (Summer ‘24 release notes: Permissions and Sharing (opens in a new tab), checked 2026-11-07). Before you add someone to a group, that’s the list of everything they’ll get.

Keep the evidence with the test

Evidence is only useful if someone else can see it later. So put it in module 2’s test plan, next to the expected result: the date, the user, the tool, and what it showed. “Sharing Hierarchy, View: Account Sharing Rule, East Region” is evidence. “Checked, looks fine” isn’t.

And check one tool with another. The Sharing Hierarchy can list someone a restriction rule blocks; UserRecordAccess ignores restriction rules; the share table doesn’t hold the role hierarchy. When two tools agree, and the three users in module 1 agree with them, you can show your work.

Test knowledge. Know where to find each kind of evidence: View Summary on the user for permissions, with Access Granted By; the Sharing Hierarchy on a record for who has access and the reason; UserRecordAccess to query a user’s access to records; the share table for rows and row causes. Know that View All Data and View All Records show as the Administrator reason and override sharing. Know that UserRecordAccess doesn’t consider restriction rules. A likely area, not a known question.

What an architect decides here

• Which evidence each test in the plan records: the tool, the date, the user and the result.
• Who can run the evidence tools, since UserRecordAccess only returns what the person running it can read.
• That Sharing Hierarchy is on the page layouts of objects with sensitive records, so admins can see it.
• Which groups are reviewed with the Public Group Access Summary before people are added.
• When a second tool confirms the first: restriction rules, the role hierarchy, and anything not stored as a row.

Beyond the exam: what AI changes. Salesforce now suggests asking an agent for the evidence: “tell the Setup agent, ‘Tell me who has access to the Acme Account record and how they have this access’” (Viewing Which Users Have Access to Your Records in Lightning Experience). That’s fast, and it’s a good start. But an answer from an agent is a claim, not evidence. Check it against the Sharing Hierarchy or a query before it goes in the test plan. And when the user you’re testing is an agent’s user, the same four tools apply to it. Chapter 20 covers agents.

Explore

• Viewing Which Users Have Access to Your Records in Lightning Experience (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Troubleshoot Object and Record Access Issues (opens in a new tab), Salesforce Help (checked 2026-11-07)
• UserRecordAccess (opens in a new tab), Object Reference, Winter ‘27 (checked 2026-11-07)
• Summer ‘24 release notes: Permissions and Sharing (opens in a new tab) (checked 2026-11-07)