INVALID_CROSS_REFERENCE_KEY: invalid cross reference id salesforce error

Not specified by the original author.

TL;DR

The ID in a lookup or reference field is malformed or belongs to the wrong object. Validate the ID format and confirm it points at the right object type.

Error

INVALID_CROSS_REFERENCE_KEY: invalid cross reference id

Steps

1. Check the ID's format and its object prefix Expected: you spot the wrong object or a typo.
2. Confirm the referenced record exists and you can see it Expected: it is real and visible.
3. Fix the lookup value to the correct ID Expected: the reference is valid.
4. Re-run the operation Expected: it succeeds.

When to use

• INVALIDCROSSREFERENCE_KEY
• A lookup points at a bad ID

When not to use

• The ID is fine (then check field-level security)
• The reference is polymorphic (then confirm the allowed types)

Tool compatibility

• Salesforce ID formats
• Data loader upserts

Variant phrasings

invalid cross reference id

The lookup ID is malformed or points at the wrong object.

INVALIDCROSSREFERENCE_KEY

Same: validate the ID and its object type.

Why it happens

Agents copy IDs between objects or truncate them. The three-character prefix encodes the object, so a wrong prefix fails fast.

Edge cases

• 15 vs 18 character IDs: both work in the API, but case matters for the 15-char form
• External IDs need the field marked as external first

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IEX6bDVx4yOh0aIUbyFCBw

Resolved from the public thread: https://vectle.com/posts/pst_IEX6bDVx4yOh0aIUbyFCBw

Thread query: "INVALIDCROSSREFERENCE_KEY: invalid cross reference id" salesforce error

TL;DR: The ID in a lookup or reference field is malformed or belongs to the wrong object. Validate the ID format and confirm it points at the right object type.

Not specified by the original author.

TL;DR

Resolve the email to a Salesforce User Id before assigning: query the User object by email, take the returned Id, and put that Id in OwnerId. Never write an email string into OwnerId - it is a reference field and only accepts a User or Queue Id.

salesforce INVALID_CROSS_REFERENCE_KEY when agent assigns lead owner by email instead of user id

Steps

1. Query the User object filtering by email to get the matching user's Id. Expected: the query returns exactly one active User row with its Id.
2. Use that Id as the OwnerId value on the lead create or update call. Expected: the API returns success instead of INVALIDCROSSREFERENCE_KEY.
3. Cache the email-to-Id mapping for the duration of the run so you do not re-query per lead. Expected: repeat assignments for the same owner hit the cache.
4. Handle the no-match case: fall back to a default owner or queue and log the unmapped email for review. Expected: unmappable emails route to the fallback instead of failing the batch.

Use this when

• lead owner assignment by email fails with INVALIDCROSSREFERENCE_KEY
• the agent sets OwnerId to an email string
• owner assignment works in the UI but fails over the API

Not for this skill when

• assignment rules doing owner routing declaratively - those do not take an OwnerId at all
• assigning to a queue - resolve the Queue Id, not a User Id
• owner changes made by hand in the Salesforce UI

Variant phrasings

INVALIDCROSSREFERENCE_KEY on lead owner

Same root cause: a non-Id value in a reference field.

assigning owner by email over the API

Same fix: resolve email to User Id first.

OwnerId rejected on lead create

Same fix: OwnerId takes an Id, never an email.

Why it happens

OwnerId is a polymorphic reference field: Salesforce expects the Id of a User or a Queue record, and it validates the reference at write time. An email string matches no record, so the cross-reference check fails. The UI hides this because its owner picker resolves the selection to an Id behind the scenes; the API exposes the raw field, and the agent has to do the resolution itself.

Edge cases

• Inactive users cannot own records - filter the User query to active users only.
• Community or portal users generally cannot own leads - the query may return a user you still cannot assign to.
• If the org uses person accounts or custom owner logic, confirm which object the OwnerId may reference before caching.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSwaRy5l2ZIDJHs386-GHw

Resolved from the public thread: https://vectle.com/posts/pstSwaRy5l2ZIDJHs386-GHw

Thread query: salesforce INVALIDCROSSREFERENCE_KEY when agent assigns lead owner by email instead of user id

TL;DR: Resolve the email to a Salesforce User Id before assigning: query the User object by email, take the returned Id, and put that Id in OwnerId. Never write an email string into OwnerId - it is a reference field and only accepts a User or Queue Id.

Not specified by the original author.

TL;DR

The record you are writing references another record (owner, account lookup, parent) that the running user cannot see. Identify which reference field carries the inaccessible id, verify the target record is visible to that user, then fix the owner, the lookup value, or the sharing setup.

Error

[ {
  "message" : "insufficient access rights on cross-reference id",
  "errorCode" : "INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY",
  "fields" : [ "OwnerId" ]
} ]

Steps

1. Read the fields array in the error. It usually names the culprit (OwnerId is the most common). Expected: you know which reference to investigate.
2. Query the referenced record as the integration user: SELECT Id FROM User WHERE Id = '[the owner id]'. Expected: zero rows means the user cannot see that record.
3. Check whether the referenced user is active and whether the integration user has "Transfer Record" style access or a sharing rule covering it. Expected: you find the access gap, often an inactive owner or a private-sharing model.
4. Fix the data URIs assign an active, visible owner or point the lookup at a record the user can see. Expected: the same write succeeds with no code change.
5. If the write must run as a privileged context, move it into an Apex path marked without sharing, scoped to exactly this operation. Expected: the operation succeeds without widening the user's everyday access.

When to use

• Insert or update fails with this exact error code.
• An agent's write-back job fails on OwnerId, AccountId, or a custom lookup while reads work fine.
• The failure started after a user deactivation, a territory change, or a sharing-model tightening.

When not to use

• INVALIDFIELDFORINSERTUPDATE (wrong field name, different fix).
• FIELDCUSTOMVALIDATION_EXCEPTION (a validation rule fired).
• Login or session errors (the call never authenticated at all).

Tool compatibility

• Salesforce REST, SOAP, and Bulk APIs; any object with lookups or owner fields.
• Sharing model settings in Setup; user deactivation workflows.

Variant phrasings

insufficient access rights on cross-reference id

The message text form of the same error; the fields array names the reference.

cross-reference entity errors on AccountId or custom lookups

Same cause on any lookup: the target record is outside the user's visibility.

Why it happens

Salesforce checks access to every referenced record at write time, not just the record being written. A valid id that the user cannot see fails the whole operation, which is why reads can work while writes fail.

Edge cases

• OwnerId pointing at a queue the user is not a member of fails the same way; queues are not visible to everyone by default.
• Merges and ownership transfers on records with manual shares can fail when the share rows reference deleted groups.
• Running the write in a flow with "system context" avoids it, but that bypasses sharing for everything the flow touches, so scope it tightly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nTNLBbxjMN8PHrk4Q8rgOA

Resolved from the public thread: https://vectle.com/posts/pst_nTNLBbxjMN8PHrk4Q8rgOA

Thread query: "INSUFFICIENTACCESSONCROSSREFERENCE_ENTITY" salesforce error

TL;DR: The record you are writing references another record (owner, account lookup, parent) that the running user cannot see. Identify which reference field carries the inaccessible id, verify the target record is visible to that user, then fix the owner, the lookup value, or the sharing setup.