Risoluzione dei problemiAccesso ai recordErrori

"Insufficient access rights on cross-reference id": come risolverlo

Cosa significa l'errore Salesforce "insufficient access rights on cross-reference id", le cinque cause che lo scatenano e come risolverlo passo dopo passo.

AgentForceAccess 3 min di lettura
Due icone di record collegate da un raggio di luce spezzato e scintillante, con un simbolo di avviso e un lucchetto

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id è uno degli errori più fraintesi di Salesforce. L’istinto è quello di controllare i permessi sul record che stai salvando, ma l’errore non riguarda quasi mai quel record. Riguarda un record diverso a cui esso punta.

Questa guida spiega cosa significa il messaggio e ti fornisce un metodo ripetibile per risolverlo.

Cosa significa davvero l’errore

Quando inserisci o aggiorni un record, Salesforce controlla anche ogni record che esso referenzia, tramite campi lookup o master-detail, ownership, oppure operazioni sulle related list. Se l’utente che esegue l’operazione non può accedere a uno di quei record referenziati, l’intera operazione viene rifiutata con insufficient access rights on cross-reference id: <id>.

L’<id> è l’ID a 15 o 18 caratteri del record che l’utente non riesce a raggiungere, non quello che si sta salvando. Questa distinzione è la chiave di tutto per risolvere il problema.

Traduci il messaggio così: “L’utente che esegue questa azione non può accedere al record correlato <id> a cui questo record punta.”

Passo 0 — Identifica il record cross-reference

Copia l’ID dall’errore e aprilo direttamente:

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

Ora sai quale oggetto e quale record ti sta bloccando (un Account padre, un Contact su un lookup, un owner, un Case correlato, ecc.). Ogni passo qui sotto riguarda quel record.

Le cinque cause, in ordine di probabilità

1. Permesso sull’oggetto mancante

Al profilo o ai permission set dell’utente manca il permesso Read (o Create/Edit) sull’oggetto referenziato. I permessi sull’oggetto sono la barriera che precede qualsiasi valutazione della condivisione: vedi permessi sull’oggetto vs condivisione dei record. Concedi i CRUD necessari tramite un permission set.

2. Field-level security sul campo lookup

L’utente non può vedere o modificare il campo che contiene il riferimento. Se la FLS nasconde il campo lookup, la scrittura su di esso fallisce. Controlla la field-level security per quel campo nel profilo/permission set dell’utente.

3. Nessun accesso al record referenziato (condivisione)

L’utente ha accesso all’oggetto ma non l’accesso al record per quello specifico record correlato. Cause possibili: un org-wide default Private senza alcuna regola di condivisione, oppure l’utente non si trova al di sopra dell’owner nella gerarchia dei ruoli. Verifica con il pulsante Sharing sul record correlato, quindi estendi l’accesso con una sharing rule, un team o una condivisione manuale.

4. Automazione eseguita nel contesto dell’utente

I Flow configurati per essere eseguiti con “How to run the flow → in user context”, oppure il codice Apex dichiarato with sharing, applicano i permessi dell’utente che esegue l’operazione. Se quell’utente non può raggiungere il record correlato, l’automazione fallisce con questo errore anche se un amministratore l’aveva testata senza problemi.

  • Soluzione A (consigliata quando appropriato): esegui il Flow in system context / Apex without sharing, così l’automazione non è limitata dall’utente che la esegue. Usala solo quando l’utente legittimamente non dovrebbe avere bisogno di un accesso diretto.
  • Soluzione B: concedi effettivamente all’utente l’accesso al record correlato (cause 1–3).

5. Un riferimento cancellato, vuoto o malformato

Il lookup punta a un record che è stato cancellato, non è mai esistito, oppure l’ID è vuoto/errato (frequente con i caricamenti di dati e le integrazioni). Salesforce segnala i record mancanti come accesso insufficiente. Verifica che l’ID corrisponda a un record attivo prima di salvare.

Una checklist di risoluzione ripetibile

  1. Estrai l’<id> dall’errore e aprilo: identifica l’oggetto e il record.
  2. L’utente ha il permesso Read/Edit sull’oggetto? → correggi il profilo/permission set.
  3. L’utente ha la field-level security sul campo lookup? → correggi la FLS.
  4. L’utente ha l’accesso al record per quello specifico record? → controlla il pulsante Sharing; aggiungi una condivisione.
  5. Un’automazione è eseguita nel contesto dell’utente? → decidi tra system context e concessione dell’accesso.
  6. L’ID referenziato corrisponde ancora a un record attivo? → correggi i dati/l’integrazione.

Il primo controllo che fallisce è la tua causa principale.

Perché questo errore è in realtà un problema di tracciamento degli accessi

Ognuna delle cause sopra riconduce alla stessa domanda di fondo: questo utente ha effettivamente accesso a quel record correlato e tramite quale meccanismo? Rispondere a mano è laborioso, dovendo considerare CRUD, FLS e sei meccanismi di condivisione.

AgentForceAccess risponde in un linguaggio chiaro: incolla l’utente e il record, e traccia esattamente quale permesso o quale condivisione concede (o blocca) l’accesso, così smetti di tirare a indovinare quale delle cinque cause stai affrontando.

Domande frequenti

A cosa si riferisce esattamente il "cross-reference id"?

È l'ID del record Salesforce del record *correlato* a cui punta la tua azione tramite un campo lookup o master-detail. L'utente che esegue l'operazione non ha accesso a quel record, quindi il salvataggio viene rifiutato. Aggiungi l'ID all'URL della tua org (https://yourdomain.my.salesforce.com/<id>) per identificarlo.

Perché la stessa azione funziona per un amministratore ma fallisce per un utente standard?

Gli amministratori di solito dispongono di "View All"/"Modify All" o "Modify All Data", che bypassano il modello di condivisione. L'utente standard viene bloccato dai permessi sull'oggetto, dalla field-level security o dalla condivisione a livello di record sul record correlato. Riproduci l'azione impersonando l'utente interessato per isolare il problema.

Eseguire un Flow in system context nasconde un vero problema di permessi?

Può succedere. Il system context ignora la condivisione e i CRUD/FLS dell'utente che esegue l'operazione: questo risolve l'errore ma può concedere un accesso che l'utente non dovrebbe avere tramite la UI. Usalo in modo consapevole e verifica che l'utente debba effettivamente poter raggiungere il record correlato.

Questo errore può derivare da un record cancellato o mancante?

Sì. Se il lookup punta a un record che è stato cancellato, non è mai esistito, oppure l'ID è vuoto/malformato, Salesforce lo segnala come accesso insufficiente anziché come "not found". Verifica che l'ID referenziato corrisponda ancora a un record attivo.

Provalo sulla tua org

AgentForceAccess spiega, in linguaggio chiaro, perché un utente può vedere un record o un file — attraverso ogni meccanismo di condivisione di Salesforce.

Richiedi accesso anticipato