"Insufficient access rights on object id": come risolverlo

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id sembra quasi identico al suo cugino cross-reference, ma indica un problema diverso. Questo riguarda il record che stai toccando direttamente: l’utente semplicemente non può scriverci.

Questa guida spiega cosa significa il messaggio, come distinguerlo dalla versione cross-reference e ti fornisce un metodo ripetibile per risolverlo.

Cosa significa davvero l’errore

Quando un utente inserisce, aggiorna o cancella un record, Salesforce verifica due cose prima di consentire la scrittura: i permessi sull’oggetto dell’utente (CRUD) e il suo accesso a livello di record (condivisione). Se uno dei due manca per il record che si sta salvando, l’operazione viene rifiutata con:

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id: <id>

L’<id> è l’ID a 15 o 18 caratteri del record che hai provato a salvare, non di uno correlato. L’utente che esegue l’operazione può vederlo, o addirittura leggerlo, ma non ha l’accesso in scrittura ad esso.

Traduci il messaggio così: “L’utente che esegue questa azione non può modificare (o cancellare) il record <id> su cui sta agendo."

"object id” vs “cross-reference id”: non confonderli

Questi due errori sono fratelli e vengono costantemente scambiati:

	`insufficient access rights on object id`	`insufficient access rights on cross-reference id`
Quale record blocca?	Il record che stai salvando	Un record correlato a cui esso punta (lookup / master-detail)
Codice di errore tipico	`INSUFFICIENT_ACCESS_OR_READONLY`	`INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY`
Prima cosa da correggere	Accesso Edit/Delete a questo record	Accesso Read al record correlato

Se l’ID nel messaggio è il record su cui hai cliccato Salva, stai leggendo l’articolo giusto. Se invece è un record padre, un owner o un record raggiunto tramite lookup, consulta insufficient access rights on cross-reference id.

Passo 0 — Identifica il record

Copia l’ID dall’errore e aprilo direttamente:

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

Conferma che sia l’oggetto e il record che ti aspettavi di salvare. Tutto ciò che segue riguarda l’accesso in scrittura a quel record.

Le quattro cause, in ordine di probabilità

1. Permesso sull’oggetto mancante (CRUD)

Al profilo o ai permission set dell’utente manca il permesso Edit (o Delete) sull’oggetto. I permessi sull’oggetto sono la barriera che precede qualsiasi valutazione della condivisione: un utente può avere pieno accesso al record ed essere comunque bloccato se non gli è concesso Edit. Vedi permessi sull’oggetto vs condivisione dei record. Concedi i CRUD necessari tramite un permission set.

2. Accesso al record in sola lettura o assente (condivisione)

L’utente ha il permesso Edit sull’oggetto, ma solo l’accesso in lettura, o nessun accesso, a questo specifico record. Cause comuni:

Un org-wide default Private senza alcuna sharing rule che raggiunga l’utente.
L’utente non si trova al di sopra dell’owner nella gerarchia dei ruoli.
Il record è condiviso in Sola lettura (sharing rule, team o condivisione manuale), il che consente di aprirlo ma non di salvarlo.

Verifica con il pulsante Sharing sul record, quindi estendi l’accesso in Lettura/Scrittura con una sharing rule, un team o una condivisione manuale. La differenza tra lettura e lettura-scrittura è esattamente ciò che separa “può aprire” da “può salvare”.

3. Nessun accesso in modifica a un padre master-detail

Se il record è il lato detail di una relazione master-detail, modificarlo richiede l’accesso al suo padre. Un utente che può solo leggere il padre (o non riesce a vederlo affatto) non può salvare il figlio: Salesforce lo segnala come accesso insufficiente sull’object id del figlio. Concedi all’utente l’accesso in lettura-scrittura al record padre.

4. Un record bloccato o in attesa di approvazione

Un record bloccato da un processo di approvazione attivo, o da un lock Apex, non può essere modificato da nessuno (amministratori a parte) finché non viene approvato, richiamato o sbloccato. Questo produce lo stesso errore anche per gli utenti che hanno effettivamente l’accesso in modifica. Controlla la cronologia di approvazione del record prima di toccare i permessi.

Causa bonus — automazione nel contesto dell’utente. Un Flow configurato per essere eseguito “in user context” o codice Apex dichiarato with sharing applicano l’accesso dell’utente che esegue l’operazione. Se quell’utente non può scrivere sul record, l’automazione fallisce con questo errore anche se un amministratore l’aveva testata senza problemi. Esegui l’automazione in system context, oppure concedi all’utente un accesso reale (cause 1–3).

Una checklist di risoluzione ripetibile

Estrai l’<id> dall’errore e aprilo: conferma quale record è fallito.
Il record è in un processo di approvazione / bloccato? → risolvi prima questo.
L’utente ha il permesso Edit/Delete sull’oggetto? → correggi il profilo/permission set.
L’utente ha l’accesso al record in lettura-scrittura (non solo lettura)? → controlla il pulsante Sharing; aggiungi una condivisione in lettura-scrittura.
È un figlio master-detail? → concedi la lettura-scrittura sul padre.
Un’automazione è eseguita nel contesto dell’utente? → decidi tra system context e concessione dell’accesso.

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 in scrittura a questo record, e tramite quale meccanismo? Rispondere a mano è laborioso, dovendo considerare CRUD, ownership, gerarchia dei ruoli e sei meccanismi di condivisione, soprattutto quando la differenza è tra lettura e lettura-scrittura.

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 in scrittura, così smetti di tirare a indovinare quale causa stai affrontando.

Domande frequenti

Qual è la differenza tra "insufficient access rights on object id" e "on cross-reference id"?

"On object id" riguarda il record che stai inserendo, aggiornando o cancellando direttamente: all'utente manca l'accesso in modifica/cancellazione a *quel* record. "On cross-reference id" riguarda invece un record *correlato* raggiunto tramite un campo lookup o master-detail. Stessa famiglia di errore, obiettivo opposto. Se l'ID nel messaggio è il record su cui hai cliccato Salva, è la versione object-id.

Perché un amministratore può modificare il record ma un utente standard riceve questo errore?

Gli amministratori di solito dispongono di "Modify All Data" o "Modify All" sull'oggetto, che bypassano gli org-wide default, le sharing rule e la gerarchia dei ruoli. L'utente standard viene bloccato dai permessi sull'oggetto o dalla condivisione a livello di record. Riproduci sempre l'azione impersonando l'utente interessato (o tramite "Login As") per isolare il problema.

L'utente ha l'accesso in lettura al record: perché continua a ricevere accesso insufficiente al salvataggio?

La lettura non basta per scrivere. Modificare o cancellare richiede il permesso Edit/Delete sull'oggetto *e* l'accesso al record in lettura-scrittura. Un record condiviso come "Sola lettura" (tramite una sharing rule, la gerarchia dei ruoli o una condivisione manuale) consente all'utente di aprirlo ma non di salvare le modifiche, e questo si manifesta come accesso insufficiente in fase di aggiornamento.

Un record bloccato o in attesa di approvazione può causare questo errore?

Sì. Mentre un record è bloccato da un processo di approvazione attivo (o da un lock Apex), nemmeno gli utenti con accesso in modifica possono salvare finché non viene approvato, richiamato o sbloccato. Verifica se il record è in un processo di approvazione prima di rincorrere i permessi.