"Insufficient access rights on cross-reference id" — how to fix it

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id is one of the most misread errors in Salesforce. The instinct is to check permissions on the record you are saving — but the error is almost never about that record. It is about a different record it points to.

This guide explains what the message means and gives you a repeatable way to fix it.

What the error actually means

When you insert or update a record, Salesforce also checks every record it references — through lookup or master-detail fields, ownership, or related-list operations. If the running user cannot access one of those referenced records, the whole operation is rejected with insufficient access rights on cross-reference id: <id>.

The <id> is the 15- or 18-character ID of the record the user can’t reach — not the one being saved. That distinction is the entire key to fixing it.

Translate the message as: “The user running this action can’t access the related record <id> that this record points to.”

Step 0 — Identify the cross-reference record

Copy the ID from the error and open it directly:

https://yourdomain.my.salesforce.com/<id>

Now you know which object and record is blocking you (a parent Account, a Contact on a lookup, an owner, a related Case, etc.). Every step below targets that record.

The five causes, in order of likelihood

1. Missing object permission

The user’s profile or permission sets lack Read (or Create/Edit) on the referenced object. Object permissions are the gate before sharing is ever evaluated — see object permissions vs record sharing. Grant the needed CRUD via a permission set.

2. Field-level security on the lookup field

The user can’t see or edit the field that holds the reference. If FLS hides the lookup field, the write to it fails. Check field-level security for that field on the user’s profile/permission sets.

3. No access to the referenced record (sharing)

The user has object access but not record access to that specific related record. Causes: a Private org-wide default with no sharing rule, or the user isn’t above the owner in the role hierarchy. Confirm with the Sharing button on the related record, then extend access with a sharing rule, team, or manual share.

4. Automation running in the user’s context

Flows configured to run “How to run the flow → in user context”, or Apex declared with sharing, enforce the running user’s permissions. If that user can’t reach the related record, the automation fails with this error even though an admin tested it fine.

• Fix A (recommended when appropriate): run the Flow in system context / Apex without sharing, so the automation isn’t limited by the running user — use only when the user legitimately shouldn’t need direct access.
• Fix B: actually grant the user access to the related record (causes 1–3).

5. A deleted, blank, or malformed reference

The lookup points to a record that was deleted, never existed, or the ID is empty/wrong (common with data loads and integrations). Salesforce reports missing records as insufficient access. Validate that the ID resolves to a live record before saving.

A repeatable fix checklist

1. Extract <id> from the error and open it — identify the object and record.
2. Does the user have object Read/Edit on that object? → fix profile/permission set.
3. Does the user have field-level security on the lookup field? → fix FLS.
4. Does the user have record access to that specific record? → check the Sharing button; add a share.
5. Is an automation running in user context? → decide between system context vs granting access.
6. Does the referenced ID still resolve to a live record? → fix the data/integration.

The first failing check is your root cause.

Why this error is really an access-tracing problem

Every cause above is the same underlying question: does this user actually have access to that related record, and through which mechanism? That’s tedious to answer by hand across CRUD, FLS, and six sharing mechanisms.

AgentForceAccess answers it in plain English — paste the user and the record, and it traces exactly which permission or share grants (or blocks) access, so you stop guessing which of the five causes you’re looking at.

Frequently asked questions

What does "cross-reference id" actually refer to?

It is the Salesforce record ID of the *related* record that your action points to through a lookup or master-detail field. The running user does not have access to that record, so the save is rejected. Append the ID to your org URL (https://yourdomain.my.salesforce.com/<id>) to identify it.

Why does the same action work for an admin but fail for a standard user?

Admins usually have "View All"/"Modify All" or "Modify All Data", which bypass the sharing model. The standard user is blocked by object permissions, field-level security, or record-level sharing on the related record. Reproduce the action as the affected user to isolate it.

Does running a Flow in system context hide a real permission problem?

It can. System context ignores the running user's sharing and CRUD/FLS, which fixes the error but may grant access the user should not have through the UI. Use it deliberately, and confirm the user genuinely should be able to reach the related record.

Can this error come from a deleted or missing record?

Yes. If the lookup points to a record that was deleted, never existed, or the ID is blank/malformed, Salesforce reports it as insufficient access rather than "not found". Verify the referenced ID still resolves to a live record.