You don't have access to this record. Ask your administrator for help.

End users see this on a record page. Admins see it three ways: the user reports it, a Lightning component fails to load, or a custom button stops working. Almost always it comes down to record-level sharing.

A short tour of who can see what

Six mechanisms grant record-level read access on a non-shared object (org-wide default = Private or Public Read-Only):

1. Owner. Every record has an owner; the owner sees it.
2. Role hierarchy. Anyone above the owner in the role hierarchy sees it (if the object's "Grant Access Using Hierarchies" is on).
3. Sharing rules. Criteria-based or owner-based rules grant access to roles, groups, or territories.
4. Manual sharing. Owner or someone above them in the hierarchy clicks Share on the record and adds a user.
5. Team membership. Account teams, opportunity teams, case teams.
6. Apex managed sharing. Custom code creates __Share records to grant access programmatically.

If a user lacks access, none of these matched. The investigation is mechanical: check each in turn.

Diagnose in 60 seconds

For the failing user + record, in Setup → Profiles → user's profile, confirm:

• Object Read is checked (otherwise they'd get a different error: Insufficient Privileges across the whole tab)

Then on the record page, click the gear → Sharing. The sharing detail page shows everyone who has access and how. If your user isn't on the list, that's the problem; one of the six mechanisms above must be the fix.

For Community / Experience Cloud users:

• Sharing Sets define how Community users see records owned by their related Account/Contact.
• The org-wide default also has an External value; if it's Private and no Sharing Set matches, the Community user can't see anything.

The "Implicit" sharing trap

When a user has access to a child record (a Contact, a Case), Salesforce implicitly grants them Read on the parent (the Account). This is a one-way, baked-in behavior. So a user who can edit a Case sees the Account header automatically — even if the Account itself isn't shared with them.

Implicit sharing trips up admins because:

• It can't be removed without unlinking the child.
• It's invisible in the Sharing button's manual-share list.
• Managed-package designers sometimes assume their users don't have parent-record visibility, then their flow breaks for users who do.

When the user has access but the page still 403s

Three possibilities to rule out:

• A Visualforce page or Lightning record page has a with sharing controller and the user lacks edit but has read. The detail page loads; the edit button errors.
• A scoped record type the user's profile doesn't include. They see the record but can't view certain fields, and a custom component using one of those fields throws.
• A formula field referencing a parent the user can't see. Account.Owner.Name returns blank, but if your downstream code does account.Owner.Name.length(), you get a NullPointerException on a record they "supposedly" have access to.

A useful one-liner

To audit access for a specific user on a specific record, in the Developer Console:

Id userId = '005...';
Id recId  = '001...';
List<UserRecordAccess> a = [
    SELECT RecordId, HasReadAccess, HasEditAccess, HasDeleteAccess, HasTransferAccess
    FROM UserRecordAccess
    WHERE UserId = :userId AND RecordId = :recId
];
System.debug(a);

If HasReadAccess is false, the user genuinely cannot see the record — no UI bug, no Lightning glitch. Fix sharing, not code.