Fix Guides

How to Fix "Insufficient Access on Cross-reference Entity" in Salesforce

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

This error means a DML operation referenced a parent record through a lookup or master-detail field — like Case.AccountId — that the running user can reference by Id, but doesn't have at least Read access to via role hierarchy, sharing rules, or ownership. It's a record-level sharing gap, not a field-level-security problem, and the fix is almost always to grant visibility to the parent record — not to change the lookup field's permissions.

Where This Shows Up

A user or Experience Cloud/Community/guest user creates or updates a record with a lookup pointing to a parent outside their sharing visibility.
A Flow or Process Builder — which always runs in the triggering user's context — sets a lookup field to a record that user can't see.
A duplicate rule, matching rule, or validation rule references a related record the running user can't see.
Apex without an explicit with sharing/without sharing declaration inherits the caller's sharing context, so the same class can behave differently depending on what invokes it.
Guest user (Experience Cloud) org-wide defaults are Private and no explicit guest-user sharing rule exists for the parent object — guest users can't inherit access via role hierarchy the way internal users can.

How to Fix It — Step by Step

1. Reproduce as the actual affected user. Use 'Login As' (or check the exact profile, permission sets, and role) for the user who hit the error — not System Administrator. Admin bypasses all sharing, so the bug won't reproduce there.
2. Identify the exact lookup field and parent object. Salesforce's error detail names the field/entity that failed the cross-reference check — usually a lookup like Case.AccountId, Contact.AccountId, or a custom lookup. Confirm which object the user can't see, not just which field.
3. Check the org-wide default for the referenced object. If OWD is Private (or Controlled by Parent and the parent is itself Private), the user needs an explicit grant: role-hierarchy visibility, a sharing rule, manual share, or ownership. Public Read Only / Public Read-Write objects generally won't produce this error for internal users.
4. Add a sharing rule or Apex managed share. Grant at least Read access to the affected user, role, or public group on the parent object — criteria-based or owner-based sharing rules for declarative access, Apex managed sharing for logic that can't be expressed declaratively.
5. For guest users, add a guest-user sharing rule specifically. Setup → Digital Experiences → Sharing Rules (guest user context). Don't widen the org-wide default as a workaround — that exposes every record of that object type, not just the ones the site actually needs.
6. For Flow and Process Builder, fix the sharing — don't route around it. Flows always run in user context; there's no 'without sharing' equivalent. Add the real sharing grant rather than shifting the DML into an Apex action specifically to bypass sharing, unless bypassing sharing is a deliberate, documented decision.
7. Re-test as the affected profile after the fix. Confirm the fix works for the actual user type that hit it (standard user, guest user, or Experience Cloud member) — not just as Admin, which will pass regardless of whether the sharing gap is actually closed.

This Error Is a Symptom, Not the Root Cause

A sharing gap on one lookup relationship is usually one instance of a broader org-wide-default and sharing-rule setup that hasn't kept pace with new objects, new automations, or a new Experience Cloud site. Run BuildForce's free health check to see how your org's overall setup compares to similar companies, then connect your org so BuildForce can evaluate sharing configuration across every object your flows, Apex, and integrations actually touch — not just the one that already failed for a real user.

How BuildForce Prevents This

Continuous health checks — evaluate org-wide defaults, sharing rules, and role hierarchy against the objects your automations actually reference.
Security scanner — flag sharing and access gaps, including guest-user exposure, before they turn into a support ticket or a compliance finding.
AI consultant for sharing debugging — describe the error and get the specific sharing rule or role change needed.

FAQ

Is this a field-level-security or object-permission problem?

Neither, usually. Field-level security controls whether a user can see the lookup field's value; object permissions control CRUD on the object itself. This error means the user has enough field/object access to reference the parent record by Id, but doesn't have record-level sharing visibility into that specific parent record — a role-hierarchy, sharing-rule, or ownership gap, not a permission-set gap.

Why does it work fine when I test as System Administrator?

Because System Administrator (and any 'View All Data' / 'Modify All Data' permission set) bypasses sharing entirely. This bug is invisible unless you reproduce it as the actual affected user — a lower-privilege internal user, a Community/Experience Cloud user, or a guest user. Testing exclusively as Admin is the single most common reason this ships to production undetected.

Can I fix this by widening field-level security on the lookup field?

No — field-level security only controls whether the user can see that the lookup field has a value, not whether they can see the record it points to. The fix has to grant record-level access to the parent (a sharing rule, manual share, role-hierarchy visibility, or ownership change), not a field permission change.

How is this different for guest users / Experience Cloud sites?

Guest users can't gain access via role hierarchy or 'Grant Access Using Hierarchies' the way internal users can (tightened as of Spring '21). They need an explicit guest-user sharing rule on the parent object under Setup → Digital Experiences → Sharing Rules. Widening the org-wide default instead of adding a scoped sharing rule is a common but risky shortcut — it exposes every record, not just the ones the flow or form actually needs.

Does BuildForce test as non-admin users automatically?

BuildForce's health checks evaluate sharing configuration — org-wide defaults, sharing rules, and role hierarchy — against the actual objects your flows, Apex, and integrations touch, so gaps like this surface as a finding instead of a support ticket from a guest or community user.

Run Free Health Check See Pricing