« Insufficient access rights on cross-reference id » : la corriger

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id est l”une des erreurs les plus mal interprétées de Salesforce. Le réflexe est de vérifier les autorisations sur l”enregistrement que vous enregistrez — mais l”erreur ne concerne presque jamais cet enregistrement. Elle concerne un autre enregistrement vers lequel il pointe.

Ce guide explique ce que signifie le message et vous donne une méthode reproductible pour le corriger.

Ce que signifie vraiment l”erreur

Lorsque vous insérez ou mettez à jour un enregistrement, Salesforce vérifie aussi chaque enregistrement qu”il référence — via des champs lookup ou master-detail, la propriété, ou des opérations sur les listes associées. Si l”utilisateur en cours ne peut pas accéder à l”un de ces enregistrements référencés, l”ensemble de l”opération est rejeté avec insufficient access rights on cross-reference id: <id>.

Le <id> est l”ID à 15 ou 18 caractères de l”enregistrement que l”utilisateur ne peut pas atteindre — et non celui en cours d”enregistrement. Cette distinction est la clé même de la résolution.

Traduisez le message ainsi : « L”utilisateur qui exécute cette action ne peut pas accéder à l”enregistrement associé <id> vers lequel cet enregistrement pointe. »

Étape 0 — Identifier l”enregistrement référencé

Copiez l”ID de l”erreur et ouvrez-le directement :

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

Vous savez désormais quel objet et quel enregistrement vous bloque (un Account parent, un Contact sur un lookup, un propriétaire, un Case associé, etc.). Chaque étape ci-dessous vise cet enregistrement.

Les cinq causes, par ordre de probabilité

1. Autorisation d”objet manquante

Le profil ou les ensembles d”autorisations de l”utilisateur n”ont pas le droit Read (ou Create/Edit) sur l”objet référencé. Les autorisations d”objet constituent la première barrière, avant même que le partage ne soit évalué — voir autorisations d”objet et partage d”enregistrement. Accordez le CRUD nécessaire via un ensemble d”autorisations.

2. Sécurité au niveau du champ sur le champ lookup

L”utilisateur ne peut pas voir ou modifier le champ qui contient la référence. Si la FLS masque le champ lookup, l”écriture dans ce champ échoue. Vérifiez la sécurité au niveau du champ pour ce champ dans le profil ou les ensembles d”autorisations de l”utilisateur.

3. Aucun accès à l”enregistrement référencé (partage)

L”utilisateur a accès à l”objet mais pas à l”enregistrement précis associé. Causes possibles : une valeur par défaut à l”échelle de l”organisation (org-wide default) en mode Private sans règle de partage, ou l”utilisateur n”est pas au-dessus du propriétaire dans la hiérarchie des rôles. Vérifiez avec le bouton Sharing sur l”enregistrement associé, puis étendez l”accès via une règle de partage, une équipe ou un partage manuel.

4. Automatisation exécutée dans le contexte de l”utilisateur

Les Flows configurés pour s”exécuter « How to run the flow → in user context », ou l”Apex déclaré with sharing, appliquent les autorisations de l”utilisateur en cours. Si cet utilisateur ne peut pas atteindre l”enregistrement associé, l”automatisation échoue avec cette erreur, même si un admin l”a testée sans problème.

Correctif A (recommandé lorsque c”est approprié) : exécutez le Flow en contexte système / l”Apex en without sharing, afin que l”automatisation ne soit pas limitée par l”utilisateur en cours — à n”utiliser que lorsque l”utilisateur n”a légitimement pas besoin d”un accès direct.
Correctif B : accordez réellement à l”utilisateur l”accès à l”enregistrement associé (causes 1 à 3).

5. Une référence supprimée, vide ou mal formée

Le lookup pointe vers un enregistrement qui a été supprimé, qui n”a jamais existé, ou dont l”ID est vide ou erroné (fréquent lors des chargements de données et des intégrations). Salesforce signale les enregistrements manquants comme un accès insuffisant. Validez que l”ID renvoie vers un enregistrement actif avant d”enregistrer.

Une checklist de résolution reproductible

Extrayez <id> de l”erreur et ouvrez-le — identifiez l”objet et l”enregistrement.
L”utilisateur a-t-il l”accès Read/Edit sur cet objet ? → corrigez le profil ou l”ensemble d”autorisations.
L”utilisateur a-t-il la sécurité au niveau du champ sur le champ lookup ? → corrigez la FLS.
L”utilisateur a-t-il l”accès à l”enregistrement précis ? → vérifiez le bouton Sharing ; ajoutez un partage.
Une automatisation s”exécute-t-elle dans le contexte utilisateur ? → choisissez entre le contexte système et l”octroi de l”accès.
L”ID référencé renvoie-t-il toujours vers un enregistrement actif ? → corrigez les données ou l”intégration.

La première vérification qui échoue est votre cause racine.

Pourquoi cette erreur est en réalité un problème de traçage d”accès

Chaque cause ci-dessus revient à la même question de fond : cet utilisateur a-t-il réellement accès à cet enregistrement associé, et par quel mécanisme ? C”est fastidieux à déterminer à la main entre le CRUD, la FLS et six mécanismes de partage.

AgentForceAccess y répond en langage clair : indiquez l”utilisateur et l”enregistrement, et l”outil retrace précisément quelle autorisation ou quel partage accorde (ou bloque) l”accès, pour que vous cessiez de deviner laquelle des cinq causes vous concerne.

Questions fréquentes

À quoi correspond réellement le « cross-reference id » ?

C'est l'ID d'enregistrement Salesforce de l'enregistrement *associé* vers lequel pointe votre action via un champ lookup ou master-detail. L'utilisateur en cours n'a pas accès à cet enregistrement, donc l'enregistrement est rejeté. Ajoutez l'ID à l'URL de votre org (https://yourdomain.my.salesforce.com/<id>) pour l'identifier.

Pourquoi la même action fonctionne-t-elle pour un admin mais échoue-t-elle pour un utilisateur standard ?

Les admins disposent généralement de « View All »/« Modify All » ou de « Modify All Data », qui contournent le modèle de partage. L'utilisateur standard est bloqué par les autorisations d'objet, la sécurité au niveau du champ ou le partage au niveau de l'enregistrement sur l'enregistrement associé. Reproduisez l'action en tant qu'utilisateur concerné pour isoler le problème.

Exécuter un Flow en contexte système masque-t-il un vrai problème d'autorisation ?

C'est possible. Le contexte système ignore le partage et le CRUD/FLS de l'utilisateur en cours, ce qui corrige l'erreur mais peut accorder un accès que l'utilisateur ne devrait pas avoir via l'interface. Utilisez-le de façon réfléchie et vérifiez que l'utilisateur devrait réellement pouvoir atteindre l'enregistrement associé.

Cette erreur peut-elle venir d'un enregistrement supprimé ou manquant ?

Oui. Si le lookup pointe vers un enregistrement supprimé, qui n'a jamais existé, ou si l'ID est vide ou mal formé, Salesforce le signale comme un accès insuffisant plutôt que comme « introuvable ». Vérifiez que l'ID référencé renvoie toujours vers un enregistrement actif.