Why Can't This User See the Record?

Module 5 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 user calls and says, “I can’t see it.” Or worse, someone can see what they shouldn’t. Where do you start, and in what order?

Every architect gets the phone call. In chapter 3 I answered it for permissions. In chapter 1 I said to ask in order: did they get in, are they in the right office, and which cabinets are open to them? This module is the whole walk, for records, in the order Salesforce itself recommends. The tools are module 4’s; this is the order to use them in.

Gather the facts first

Before you click anything, Salesforce says to gather three things (Troubleshooting User Access Issues and Insufficient Privileges Errors (opens in a new tab), Salesforce Help, checked 2026-11-07):

“What objects, records, fields, and features are involved in the issue?”
“For the user with the access issue, what are the user’s profile, permission sets, and role?”
“If it’s a record access issue, what is the record owner’s role?”

Then decide which kind of problem it is. Salesforce has a walk-through for each: object and record access, field access, feature access, and external users (same page). Most calls about “I can’t see it” are the first kind, so start there.

Can’t see the record: the walk, in order

Salesforce’s walk-through for a missing record has twelve steps. I group them in four, and the order matters, because each group rules out the one before (Troubleshoot Object and Record Access Issues (opens in a new tab), Salesforce Help, checked 2026-11-07).

Click to enlarge

1. The object

“Check if the user has the relevant object permissions. Go to the user’s detail page in Setup, and click View Summary.” If Read isn’t there, no sharing in the world will show them the record. If it is, “This issue involves record access, not object permissions” (same page). In class I put it this way: the file cabinet controls don’t affect whether you can or can’t see an object. They affect whether you can or can’t see records in that object. So settle the object first.

2. The default

Check the org-wide default on the Sharing Settings page. Salesforce gives three branches (same page):

Public Read/Write: “There are no regular access restrictions for this object’s records.” Skip to the last group, what takes access away.
Controlled by Parent: “The parent object controls access. Start step 2 again for the parent object.”
Private: “Only record owners and users above them in the role hierarchy can access this object.” On a custom object, also check whether Grant Access Using Hierarchies is turned off.

3. The grants

Now find the grant that should be there. Start with the record’s Sharing Hierarchy, from module 4: “this list can help inform why your user is missing access.” If you expected the user to get access through one of the listed reasons, “you can jump directly to that feature” (same page). If not, walk the grants in Salesforce’s order:

The role, against the owner’s role.
Public groups: is the user in the groups the rules and shares target? A group’s own View Summary shows where it’s used.
Sharing rules: does a rule exist for this, with the right records, the right access level, and the user really in its target?
Queues, teams and territories: the right membership, and the record in the right place.
Manual shares: if the user had access and lost it, Salesforce names the usual reasons: “The record owner changed, causing the manual share to be removed,” someone removed the share, or a restriction rule blocks it.
Code: “if you’re sharing records programmatically using Apex, verify that your code is working correctly.”

That’s the course in order: chapters 6 to 11, as a checklist.

4. What takes it away

Last, the things that remove access the grants gave: “Restriction rules prevent users from accessing records if they meet certain criteria,” and “Custom Apex logic can be used to restrict users’ access to data” (same page). The Sharing Hierarchy tells you when a restriction rule blocks a user.

Can see what they shouldn’t: the other direction

The opposite call is the more dangerous one. Salesforce’s walk is shorter (same page):

Start with the permissions. View Summary, the Object Permissions tab, and Access Granted By on any permission they shouldn’t have. And remember: “if users are assigned the View All Records or Modify All Records permissions for an object, they have access to all records of that object, regardless of the sharing settings.” The same goes for View All Data and Modify All Data.
Then the record. The Sharing Hierarchy’s reasons tell you which role, group, rule or share opened it.
Then code that writes shares.

Fix the cause, not the user. If a group opened the record, changing the group changes it for everyone in the group, so look at the Public Group Access Summary first.

Can’t see a field

A field is its own walk (Troubleshoot Field Access Issues (opens in a new tab), Salesforce Help, checked 2026-11-07): View Summary, the Field Permissions tab; then the page layouts the user’s profile assigns; then validation rules; then custom code. For lookups and system fields, check the “Require permission to view record names in lookup fields” setting.

And one fact that surprises people: “View All Data, Modify All Data, and View All Records or Modify All Records permissions for a given object don’t override field-level security. Users must still have field permissions to read or edit each field on an object” (same page). The big permissions open every record, not every field. That’s chapter 4.

The traps

Salesforce collects the ones that waste the most time (Additional Considerations for Troubleshooting Access Issues (opens in a new tab), Salesforce Help, checked 2026-11-07):

The wrong object. “If a user is manually sharing a case, the receiving user must have at least Read access to the associated parent account.” When the error is about a case, check the account too.
Automation. Editing a record “can trigger a workflow that involves additional objects that the user doesn’t have access to. Or, if record ownership is changed inside the workflow, the user can lose access.”
Private records. Private contacts, “contacts that aren’t associated with an account,” and private opportunities, where “the Private field is true,” aren’t affected by your sharing: “sharing rules don’t apply.”
Recalculation, last. “If you exhaust all sharing rule troubleshooting options, and access still isn’t as expected, you can consider recalculating an object’s sharing rules.” Only then, because it can take a while.

External users

Sharing works differently outside the company. “Unauthenticated guest users can only receive access from guest user sharing rules.” Their external defaults are always Private, and they can’t receive manual shares. High-volume users have no roles; sharing sets and share groups decide what they see (Additional Considerations). Salesforce has separate walk-throughs for customer and partner users, high-volume users and guest users (Troubleshoot Access Issues for External Users (opens in a new tab), Salesforce Help, checked 2026-11-07). Part 3 of this course covers them, starting with chapter 14.

When the screens aren’t enough: queries

Salesforce publishes sample queries for the same questions (Example Queries for Troubleshooting Access Issues (opens in a new tab), Salesforce Help, checked 2026-11-07). Two I use most, in its shape. Which of this user’s permission sets give Read on cases?

SELECT PermissionSetId, PermissionSet.Name, PermissionSetGroupId, ExpirationDate
FROM PermissionSetAssignment
WHERE AssigneeId = '<the user>'
AND PermissionSetId IN
    (SELECT ParentId FROM ObjectPermissions
     WHERE SobjectType = 'Case' AND PermissionsRead = true)

And can this user see this record, and how far? That’s UserRecordAccess, from module 4. The same page notes that profiles and permission set groups each have an associated permission set, so the same queries work for them.

Then prove the fix

A fix isn’t done when the user stops calling. Run module 1’s three users again: the user who couldn’t see it now can, the user who shouldn’t still can’t, and the side effects are what you meant. Write it in the test plan with module 4’s evidence. The next call about the same record should start from that page.

Test knowledge. Know the order: object permissions first, then the org-wide default, then the grants, then what takes access away. Know that Controlled by Parent sends you to the parent, that View All Records and View All Data override sharing but not field-level security, and that a manual share is lost when the owner changes by default. Know that guest users get access only through guest user sharing rules and high-volume users through sharing sets and share groups. A likely area, not a known question.

What an architect decides here

The troubleshooting order the team follows, written down, so every call starts the same way.
Who can see the evidence tools: View Summary, the Sharing Hierarchy on page layouts, and the queries.
Which automation can change record owners, since it can take access away without anyone noticing.
Whether private contacts and private opportunities are allowed, knowing sharing doesn’t reach them.
That every fix ends with the three users and an entry in the test plan.

Beyond the exam: what AI changes. Every one of these Salesforce pages now opens with a tip: get help from Setup with Agentforce, and ask it why a user can or can’t see a record or a field (Troubleshoot Object and Record Access Issues). Use it to find the step faster. But walk the answer back through this order, and check it with module 4’s tools before you change anything. And when the user who can’t see something is an agent’s user, the walk is the same: object, default, grants, what takes it away. Chapter 20 covers agents.

Explore

Troubleshooting User Access Issues and Insufficient Privileges Errors (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)
Troubleshoot Field Access Issues (opens in a new tab), Salesforce Help (checked 2026-11-07)
Additional Considerations for Troubleshooting Access Issues (opens in a new tab), Salesforce Help (checked 2026-11-07)
Troubleshoot Access Issues for External Users (opens in a new tab), Salesforce Help (checked 2026-11-07)
Example Queries for Troubleshooting Access Issues (opens in a new tab), Salesforce Help (checked 2026-11-07)