"Insufficient access rights on object id" oplossen

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id lijkt bijna identiek aan zijn cross-referenceneef, maar wijst op een ander probleem. Deze gaat over het record dat je direct aanraakt — de gebruiker kan er simpelweg niet naar schrijven.

Deze gids legt uit wat het bericht betekent, hoe je het onderscheidt van de cross-referenceversie, en geeft je een herhaalbare manier om het op te lossen.

Wat de fout werkelijk betekent

Wanneer een gebruiker een record invoegt, bijwerkt of verwijdert, controleert Salesforce twee dingen voordat het schrijven wordt toegestaan: de objectrechten van de gebruiker (CRUD) en zijn recordtoegang (deling). Als een van beide ontbreekt voor het record dat wordt opgeslagen, wordt de bewerking geweigerd met:

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

De <id> is de 15- of 18-cijferige ID van het record dat je probeerde op te slaan — niet een gerelateerd record. De uitvoerende gebruiker kan het zien, of zelfs lezen, maar heeft geen schrijftoegang ertoe.

Lees het bericht als: “De gebruiker die deze actie uitvoert, kan het record <id> waarop hij handelt niet bewerken (of verwijderen)."

"object id” vs “cross-reference id” — verwar ze niet

Deze twee fouten zijn broers en worden voortdurend door elkaar gehaald:

	`insufficient access rights on object id`	`insufficient access rights on cross-reference id`
Welk record blokkeert?	Het record dat je opslaat	Een gerelateerd record waarnaar het verwijst (lookup / master-detail)
Typische foutcode	`INSUFFICIENT_ACCESS_OR_READONLY`	`INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY`
Eerst op te lossen	Bewerk-/verwijdertoegang tot dit record	Leestoegang tot het gerelateerde record

Als de ID in het bericht het record is waarop je Opslaan klikte, dan lees je het juiste artikel. Als het een bovenliggend, eigenaars- of opgezocht record is, lees dan in plaats daarvan insufficient access rights on cross-reference id.

Stap 0 — Identificeer het record

Kopieer de ID uit de fout en open hem rechtstreeks:

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

Bevestig dat het het object en record is dat je verwachtte op te slaan. Alles hieronder richt zich op schrijftoegang tot dat record.

De vier oorzaken, in volgorde van waarschijnlijkheid

1. Ontbrekende objectrechten (CRUD)

Het profiel of de permission sets van de gebruiker missen Edit (of Delete) op het object. Objectrechten zijn de poort voordat deling überhaupt wordt geëvalueerd — een gebruiker kan volledige recordtoegang hebben en toch geblokkeerd worden als Edit niet is toegekend. Zie objectrechten versus recorddeling. Ken de benodigde CRUD toe via een permission set.

2. Read-only of geen recordtoegang (deling)

De gebruiker heeft object-Edit, maar slechts leestoegang — of geen toegang — tot dit specifieke record. Gangbare oorzaken:

Een Private org-wide default zonder sharing rule die de gebruiker bereikt.
De gebruiker staat niet boven de eigenaar in de rolhiërarchie.
Het record is gedeeld als Read Only (sharing rule, team of handmatige deling), wat openen wel maar opslaan niet toestaat.

Bevestig dit met de knop Sharing op het record en breid vervolgens de Read/Write-toegang uit met een sharing rule, team of handmatige deling. Het verschil tussen lezen en lees-schrijven is hier precies wat “kan openen” scheidt van “kan opslaan”.

3. Geen bewerktoegang tot een master-detail-bovenliggend record

Als het record de detailzijde van een master-detailrelatie is, vereist het bewerken ervan toegang tot het bovenliggende record. Een gebruiker die het bovenliggende record alleen kan lezen (of het helemaal niet kan zien) kan het onderliggende record niet opslaan — Salesforce meldt dit als onvoldoende toegang op de object-id van het onderliggende record. Geef de gebruiker lees-schrijftoegang tot het bovenliggende record.

4. Een vergrendeld of op-goedkeuring-wachtend record

Een record dat is vergrendeld door een actief goedkeuringsproces — of door een Apex-lock — kan door niemand worden bewerkt (admins daargelaten) totdat het is goedgekeurd, ingetrokken of ontgrendeld. Dit produceert dezelfde fout, zelfs voor gebruikers die echt bewerktoegang hebben. Controleer de goedkeuringsgeschiedenis van het record voordat je rechten aanraakt.

Bonusoorzaak — automatisering in gebruikerscontext. Een Flow die is ingesteld om te draaien “in user context” of Apex gedeclareerd als with sharing dwingt de toegang van de uitvoerende gebruiker af. Als die gebruiker niet naar het record kan schrijven, mislukt de automatisering met deze fout, ook al testte een admin het probleemloos. Laat de automatisering ofwel in systeemcontext draaien, of geef de gebruiker echte toegang (oorzaken 1–3).

Een herhaalbare oplossingschecklist

Haal <id> uit de fout en open hem — bevestig welk record mislukte.
Zit het record in een goedkeuringsproces / is het vergrendeld? → los dat eerst op.
Heeft de gebruiker object-Edit/Delete op dat object? → corrigeer het profiel/de permission set.
Heeft de gebruiker lees-schrijf-recordtoegang (niet alleen lezen)? → controleer de knop Sharing; voeg een lees-schrijfdeling toe.
Is het een master-detail-onderliggend record? → ken lees-schrijftoegang toe op het bovenliggende record.
Draait er een automatisering in gebruikerscontext? → kies tussen systeemcontext en het verlenen van toegang.

De eerste mislukte controle is je grondoorzaak.

Waarom deze fout eigenlijk een toegangstraceringsprobleem is

Elke oorzaak hierboven is dezelfde onderliggende vraag: heeft deze gebruiker daadwerkelijk schrijftoegang tot dit record, en via welk mechanisme? Dat is moeizaam om met de hand te beantwoorden over CRUD, eigenaarschap, de rolhiërarchie en zes deelmechanismen heen — vooral wanneer lezen versus lees-schrijven het verschil maakt.

AgentForceAccess beantwoordt het in gewoon Nederlands — plak de gebruiker en het record erin, en het traceert precies welk recht of welke deling schrijftoegang verleent (of blokkeert), zodat je niet langer hoeft te raden naar welke oorzaak je kijkt.

Veelgestelde vragen

Wat is het verschil tussen "insufficient access rights on object id" en "on cross-reference id"?

"On object id" gaat over het record dat je direct invoegt, bijwerkt of verwijdert — de gebruiker mist bewerk-/verwijdertoegang tot *dat* record. "On cross-reference id" gaat over een *gerelateerd* record dat via een lookup- of master-detailveld wordt bereikt. Dezelfde foutfamilie, tegenovergesteld doelwit. Als de ID in het bericht het record is waarop je Opslaan klikte, dan is het de object-id-versie.

Waarom kan een admin het record wel bewerken maar krijgt een standaardgebruiker deze fout?

Admins hebben meestal "Modify All Data" of "Modify All" op het object, die org-wide defaults, sharing rules en de rolhiërarchie omzeilen. De standaardgebruiker wordt geblokkeerd door objectrechten of recorddeling. Reproduceer de actie altijd terwijl je bent ingelogd als (of via "Login As") de getroffen gebruiker om het te isoleren.

De gebruiker heeft Read-toegang tot het record — waarom dan toch onvoldoende toegang bij het opslaan?

Read is niet genoeg om te schrijven. Bewerken of verwijderen vereist Edit/Delete-objectrechten *en* lees-schrijf-recordtoegang. Een record dat als "Read Only" is gedeeld (via een sharing rule, rolhiërarchie of handmatige deling) laat de gebruiker het openen maar geen wijzigingen opslaan, wat zich uit als onvoldoende toegang bij het bijwerken.

Kan een vergrendeld of op-goedkeuring-wachtend record deze fout veroorzaken?

Ja. Zolang een record is vergrendeld door een actief goedkeuringsproces (of een Apex-lock), kunnen zelfs gebruikers met bewerktoegang niet opslaan totdat het is goedgekeurd, ingetrokken of ontgrendeld. Controleer of het record in een goedkeuringsproces zit voordat je rechten gaat najagen.