TL;DR: Salesforce is blocking your operation because the running user does not have access to a record referenced by the action.
This includes parent records, related records, junction objects, or any ID used in DML, sharing, lookup, or relationship fields.

The error appears as:
INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id

This is a permissions error — not a logic or data volume issue — and it typically means the user cannot see, edit, or reference a record that the automation is trying to touch.

What This Error Actually Means

When Salesforce encounters a record ID during a save operation, it checks whether the running user has the right to interact with that record.

If the user lacks access (read, edit, delete, share, or reference), Salesforce immediately stops the transaction.

This can occur during:

• A Flow
• An Apex trigger or class
• A Process Builder
• A validation rule referencing a record
• A lookup update
• A sharing rule operation
• A managed package process
• An integration call

In short:
The user is touching a record they are not allowed to touch.

What “Cross-Reference Entity” Refers To

A “cross-reference entity” is any record Salesforce must access as part of your operation. Common examples:

• The parent record in a lookup or master-detail
• The record being updated via automation
• A related record used in a Formula or Flow condition
• A record being created or linked via DML
• A User record referenced in ownership or sharing
• A managed package object your automation interacts with

If any of these is inaccessible, the whole transaction fails.

Common Causes of INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY

1. User Lacks Object or Field Permissions

You reference a field the user cannot read/edit, or an object the user cannot access.

Examples:

• A Flow updates a lookup field the user can’t modify
• A trigger updates an object the user can’t edit
• PB tries to write to a field hidden by FLS

2. Sharing Settings Block Access

Even with object permissions, the user may not have record-level access.

Scenarios:

• Private OWD
• Missing sharing rules
• Missing role hierarchy access
• Parent record belongs to another restricted user

3. Automation Running in User Context

Flows run in user context unless specified otherwise. If they reference parent/child records the user can’t see, the error is triggered.

(Apex may run in system context, but not always.)

4. Lookup or Master-Detail References an Inaccessible Record

If you're setting a lookup field to a record the user can’t see, Salesforce rejects the update.

Example:
Trying to set Account on a Contact when the user can't access that Account.

5. Managed Package Objects with Restricted Sharing

Packages often include custom sharing models.
Your user may lack access even if the object is technically visible.

6. Integrations Authenticating as a Low-Privilege User

Common culprit: middleware authenticates as a user with restricted permissions, causing failures during record creation or linking.

How to Diagnose the Error

Step 1 — Identify the ID in the Error

The error usually includes an ID.
Use that ID to check:

• Is this record restricted?
• Is it owned by someone else?
• Is it part of a private OWD model?

Step 2 — Check FLS and Profiles

Make sure the running user can:

• Read the record
• Edit the record
• Modify the lookup or relationship field

Step 3 — Evaluate Sharing Model

If OWD = Private or Controlled by Parent, confirm:

• Role hierarchy
• Sharing rules
• Manual sharing
• Team access (e.g., Account teams)

Step 4 — Review Flows, PB, and Apex Context

Flows with “User Context” are the #1 modern cause.

Check:

• Does the Flow use “Run As System”?
• Is Apex using with sharing?
• Is a managed package enforcing its own sharing?

Step 5 — Follow the Automation Chain

Many errors come from automation referencing deeply nested relationships.

Example:
Flow updates a Contact → references Account.Owner → queries Opportunity → references a private Quote → error.

How to Fix It

Quick Wins

• Grant read/edit access to the necessary objects and fields
• Add sharing rules for involved records
• Move automation to system context where appropriate
• Avoid referencing deeply restricted related records
• Use “before save” when possible (fewer field-level restrictions)
• Ensure lookups aren’t being set to records users can’t see

Architectural Fixes

• Align OWD, roles, and sharing rules with automation needs
• Centralize access models to avoid hidden restrictions
• Standardize which automations run in system vs. user context
• Update integration users to use an appropriate permission set

Your Prevention Checklist

Before you deploy:

• Does this automation touch objects the user can’t see?
• Does it reference related records across multiple sharing models?
• Does the running user have FLS for all fields involved?
• Should this automation run as system context?
• Do parent records belong to a private OWD structure?
• Is a managed package introducing hidden sharing logic?

When This Error Comes from an Integration

Common signs:

• API user can insert a record but not set a lookup
• Integration can create records but fails on updates
• Ownership or sharing logic triggers unexpected restrictions

Fixes:

• Update the integration user’s permission set
• Use field-level security to grant visibility
• Ensure parent records are accessible
• Avoid unnecessary lookups during ingestion

The Takeaway

This is not a data problem — it’s an access problem. To fix it, you must understand who can see what, how your sharing model works, and where your automation runs in user vs. system context.

Once you solve the access mismatch, the error disappears.

Using Sweep? Here’s How to Diagnose Access Issues Instantly

Sweep helps with:

1. Identifying which automation references restricted records

See every Flow, trigger, and reference that touches related records across objects.

2. Mapping execution chains that cause permission failures

Spot where a Flow or PB tries to access a record the user cannot see.

3. Documenting context (user vs. system)

Sweep’s metadata documentation shows which automations run with user permissions, helping you avoid permission-based failures.

4. Preventing the error before deployment

Impact Analysis flags:

• Cross-object references
• Restricted lookups
• Flows that run in user context touching private records
• Automation that requires system-level access

See how Sweep visualizes automation dependencies, object relationships, and execution context so you can spot permission conflicts immediately. Explore the Automation Map