A user cannot see some records in Salesforce — how do you debug it? | CRM Curator

A user says they can’t see a record they should have access to. The fastest path to root cause is to walk the Salesforce sharing model in the same order the platform evaluates it: Org-Wide Defaults → role hierarchy → sharing rules → manual / Apex sharing → team-based sharing. If the user still doesn’t get access after all five layers, the problem is at the field, record type, or page-layout layer, not record-level sharing.

The 60-second answer

Open the record, click Sharing (or Sharing Hierarchy on Lightning), and check who has access. Use Setup → Login As to log in as the user and confirm. If the record isn’t even in their list view, the issue is record-level sharing (OWD, role, sharing rules, manual share, team). If they can open the record but a specific field is blank, it’s field-level security or page layout. If the record exists in their org but in a different record type they can’t see, it’s record-type assignment on their profile.

How Salesforce evaluates record access (the order matters)

Most restrictive (OWD)  →  Layers that grant access
─────────────────────────────────────────────────
Private                  →  + Role hierarchy ("Grant Access Using Hierarchies")
                         →  + Owner-based sharing rules
                         →  + Criteria-based sharing rules
                         →  + Manual share (Sharing button)
                         →  + Apex managed sharing
                         →  + Team sharing (Account/Opportunity/Case teams)
                         →  + Implicit parent/child sharing

Access is additive once OWD is set. The user only loses visibility because the bottom layer (OWD) is restrictive and no upper layer added them in. So debugging is about walking up from OWD until you find — or don’t find — the layer that should have granted access.

Step-by-step debugging checklist

1. Confirm what “can’t see” actually means

Ask the user:

“Can you find it in a list view but get an ‘insufficient privileges’ error?” → record-level sharing or FLS.
“It’s not in the list view at all?” → record-level sharing.
“I can open it but field X is blank?” → field-level security or formula field issue.
“I see it in production but not in the sandbox?” → data refresh / record-type / page layout mismatch.

2. Check OWD for the object

Setup → Sharing Settings → Organization-Wide Defaults. If the object is Public Read/Write, the user already has access — the problem is FLS or layout, not record sharing. If it’s Private or Public Read Only, continue.

3. Check the user’s role and the “Grant Access Using Hierarchies” flag

If the record is owned by someone below the user in the role hierarchy AND “Grant Access Using Hierarchies” is checked for the object → the user should have access via the hierarchy. If hierarchies are off (common for custom objects), this path doesn’t help.

Setup → Sharing Settings → [object] Sharing Rules. Look at owner-based and criteria-based rules. Does the user’s role or public group appear in a rule that matches this record? Note that sharing rules only fire on insert/update — if a rule was added after the record was created and never re-saved, the rule may not have rebuilt yet. Setup → Sharing Settings → Recalculate forces a rebuild.

Open the record → Sharing button (Classic) or Sharing Hierarchy (Lightning). This shows every reason the access exists, including manual shares and Apex shares. If the user appears here with no access, you’ve found the problem. If they’re absent, no layer is granting them in.

Setup → Users → next to the user, click Login. Try to open the record by direct URL. The platform will tell you exactly why access is denied (“insufficient privileges”, “record does not exist or has been deleted”, etc.).

7. If access is fine but a field is blank — check FLS

Setup → Object Manager → [object] → Fields & Relationships → [field] → Set Field-Level Security. Confirm the user’s profile and permission sets grant Visible for that field.

8. If the record itself looks wrong — check record types and page layouts

Setup → Profiles → [profile] → Record Type Settings and Page Layout Assignment. A user can have access to a record but see a different layout that hides sections.

A debugging script you can paste into Developer Console

// Replace IDs as needed
Id recordId  = '0011x00000XXXXX';
Id userId    = '0051x00000XXXXX';

UserRecordAccess access = [
    SELECT RecordId, HasReadAccess, HasEditAccess, HasDeleteAccess,
           HasTransferAccess, MaxAccessLevel
    FROM   UserRecordAccess
    WHERE  UserId   = :userId
    AND    RecordId = :recordId
];
System.debug('Access: ' + access);

UserRecordAccess is a virtual SOQL object that returns the effective access level the runtime would grant. If HasReadAccess is false, the user genuinely has no read — keep walking the layers above.

Common mistakes interviewers want to catch

Stopping at “they don’t own it.” Ownership is one layer of many. A sharing rule or team can still grant access.
Forgetting the role-hierarchy checkbox. Custom objects default to “Grant Access Using Hierarchies = ON,” but you can turn it off, and many orgs do.
Forgetting implicit sharing. Access to an Account implicitly grants access to its child Contacts/Opportunities for the owner — but not for read-only users unless you opted in.
Confusing FLS with record sharing. “Can’t see the field” ≠ “can’t see the record.”
Not using Login As. Reading config is slow. Logging in as the user takes 10 seconds.

How to answer in 30 seconds

“I walk the sharing model: OWD, role hierarchy, sharing rules, manual / Apex share. The fastest tool is the Sharing button on the record plus Login As the user — that tells me the real effective access. If the record is visible but a field is blank, it’s field-level security, not record sharing.”

How to answer in 2 minutes

Add the diagnostic order above (UserRecordAccess SOQL), the distinction between record-level sharing vs FLS vs page-layout vs record-type, the recalculation gotcha on sharing rules added after data load, and the role-hierarchy “Grant Access Using Hierarchies” checkbox. Mention implicit parent/child sharing for Account-related objects.

Likely follow-up questions

What’s the difference between a sharing rule and a manual share?
When does the platform recalculate sharing automatically vs. manually?
How would you grant access programmatically to a record owned by another user?
What’s Apex managed sharing and when do you need it?
Why does changing OWD trigger a long-running recalculation job?

Verified against: Salesforce Security Guide — Sharing Model, UserRecordAccess, Login As. Last reviewed 2026-05-19.