"Insufficient access rights on object id" beheben

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id sieht seinem Cross-Reference-Verwandten fast identisch aus, weist aber auf ein anderes Problem hin. Hier geht es um den Datensatz, den Sie direkt anfassen — der Benutzer kann schlicht nicht darauf schreiben.

Dieser Leitfaden erklärt, was die Meldung bedeutet, wie Sie sie von der Cross-Reference-Variante unterscheiden und gibt Ihnen ein wiederholbares Vorgehen zur Behebung an die Hand.

Was der Fehler wirklich bedeutet

Wenn ein Benutzer einen Datensatz einfügt, aktualisiert oder löscht, prüft Salesforce zwei Dinge, bevor der Schreibvorgang zugelassen wird: die Objektberechtigungen des Benutzers (CRUD) und seinen Zugriff auf Datensatzebene (Sharing). Fehlt eines davon für den zu speichernden Datensatz, wird die Operation abgelehnt mit:

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

Die <id> ist die 15- oder 18-stellige ID des Datensatzes, den Sie zu speichern versucht haben — nicht die eines verknüpften. Der ausführende Benutzer kann ihn sehen oder sogar lesen, hat aber keinen Schreibzugriff darauf.

Übersetzen Sie die Meldung als: “Der Benutzer, der diese Aktion ausführt, kann den Datensatz <id>, an dem er arbeitet, nicht bearbeiten (oder löschen)."

"object id” vs. “cross-reference id” — nicht verwechseln

Diese beiden Fehler sind Geschwister und werden ständig durcheinandergebracht:

	`insufficient access rights on object id`	`insufficient access rights on cross-reference id`
Welcher Datensatz blockiert?	Der Datensatz, den Sie speichern	Ein verknüpfter Datensatz, auf den er verweist (Lookup / Master-Detail)
Typischer Fehlercode	`INSUFFICIENT_ACCESS_OR_READONLY`	`INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY`
Zuerst zu beheben	Edit/Delete-Zugriff auf diesen Datensatz	Read-Zugriff auf den verknüpften Datensatz

Wenn die ID in der Meldung der Datensatz ist, auf dem Sie Speichern geklickt haben, lesen Sie den richtigen Artikel. Handelt es sich um einen übergeordneten, einen Eigentümer- oder einen per Lookup referenzierten Datensatz, lesen Sie stattdessen insufficient access rights on cross-reference id.

Schritt 0 — Den Datensatz identifizieren

Kopieren Sie die ID aus dem Fehler und öffnen Sie sie direkt:

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

Bestätigen Sie, dass es sich um das Objekt und den Datensatz handelt, den Sie speichern wollten. Alles Folgende zielt auf den Schreibzugriff auf diesen Datensatz ab.

Die vier Ursachen, nach Häufigkeit geordnet

1. Fehlende Objektberechtigung (CRUD)

Dem Profil oder den Permission Sets des Benutzers fehlt Edit (oder Delete) auf dem Objekt. Objektberechtigungen sind die Schranke, bevor Sharing überhaupt geprüft wird — ein Benutzer kann vollen Datensatzzugriff haben und trotzdem blockiert sein, wenn Edit nicht vergeben ist. Siehe Objektberechtigungen vs. Datensatz-Sharing. Vergeben Sie die nötigen CRUD-Rechte über ein Permission Set.

Der Benutzer hat Edit auf dem Objekt, aber nur lesenden Zugriff — oder gar keinen — auf diesen konkreten Datensatz. Häufige Ursachen:

Ein Private-Org-Weiter-Standardwert (OWD) ohne Sharing-Regel, die den Benutzer erreicht.
Der Benutzer steht in der Rollenhierarchie nicht über dem Eigentümer.
Der Datensatz ist Read Only freigegeben (Sharing-Regel, Team oder manuelle Freigabe), was das Öffnen, aber nicht das Speichern erlaubt.

Bestätigen Sie dies über die Schaltfläche Sharing auf dem Datensatz und erweitern Sie den Zugriff anschließend auf Read/Write per Sharing-Regel, Team oder manueller Freigabe. Der Unterschied zwischen lesend und lesend-schreibend ist hier genau das, was “kann öffnen” von “kann speichern” trennt.

3. Kein Schreibzugriff auf einen Master-Detail-Übergeordneten

Ist der Datensatz die Detail-Seite einer Master-Detail-Beziehung, erfordert seine Bearbeitung Zugriff auf den übergeordneten Datensatz. Ein Benutzer, der den Übergeordneten nur lesen kann (oder ihn gar nicht sieht), kann den untergeordneten Datensatz nicht speichern — Salesforce meldet dies als unzureichende Zugriffsrechte auf der Object id des untergeordneten Datensatzes. Gewähren Sie dem Benutzer Lese-Schreib-Zugriff auf den übergeordneten Datensatz.

4. Ein gesperrter oder genehmigungspflichtiger Datensatz

Ein Datensatz, der durch einen aktiven Genehmigungsprozess — oder eine Apex-lock — gesperrt ist, kann von niemandem (Admins ausgenommen) bearbeitet werden, bis er genehmigt, zurückgezogen oder entsperrt wird. Das erzeugt denselben Fehler selbst bei Benutzern, die tatsächlich Schreibzugriff haben. Prüfen Sie die Genehmigungshistorie des Datensatzes, bevor Sie an den Berechtigungen ansetzen.

Zusatzursache — Automatisierung im Benutzerkontext. Ein Flow, der “im Benutzerkontext” laufen soll, oder Apex, das als with sharing deklariert ist, erzwingt den Zugriff des ausführenden Benutzers. Kann dieser Benutzer nicht auf den Datensatz schreiben, scheitert die Automatisierung mit diesem Fehler — obwohl der Test beim Admin einwandfrei lief. Führen Sie die Automatisierung entweder im Systemkontext aus oder gewähren Sie dem Benutzer echten Zugriff (Ursachen 1–3).

Eine wiederholbare Checkliste zur Behebung

Extrahieren Sie <id> aus dem Fehler und öffnen Sie sie — bestätigen Sie, welcher Datensatz fehlgeschlagen ist.
Befindet sich der Datensatz in einem Genehmigungsprozess / ist er gesperrt? → zuerst das lösen.
Hat der Benutzer Edit/Delete auf diesem Objekt? → Profil/Permission Set korrigieren.
Hat der Benutzer Lese-Schreib-Zugriff auf den Datensatz (nicht nur lesend)? → Schaltfläche Sharing prüfen; eine Lese-Schreib-Freigabe hinzufügen.
Handelt es sich um einen Master-Detail-untergeordneten Datensatz? → Lese-Schreib-Zugriff auf den Übergeordneten gewähren.
Läuft eine Automatisierung im Benutzerkontext? → zwischen Systemkontext und Zugriffsvergabe entscheiden.

Die erste fehlschlagende Prüfung ist Ihre Grundursache.

Warum dieser Fehler in Wahrheit ein Zugriffs-Tracing-Problem ist

Jede Ursache oben läuft auf dieselbe grundlegende Frage hinaus: Hat dieser Benutzer tatsächlich Schreibzugriff auf diesen Datensatz — und über welchen Mechanismus? Das von Hand über CRUD, Eigentümerschaft, die Rollenhierarchie und sechs Sharing-Mechanismen hinweg zu beantworten, ist mühsam — besonders wenn lesend vs. lesend-schreibend den Unterschied macht.

AgentForceAccess beantwortet die Frage in verständlicher Sprache — geben Sie Benutzer und Datensatz ein, und es verfolgt exakt nach, welche Berechtigung oder Freigabe den Schreibzugriff gewährt (oder blockiert), sodass Sie nicht länger raten müssen, welche Ursache vorliegt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen "insufficient access rights on object id" und "on cross-reference id"?

"On object id" betrifft den Datensatz, den Sie direkt einfügen, aktualisieren oder löschen — dem Benutzer fehlt der Schreib-/Löschzugriff auf *diesen* Datensatz. "On cross-reference id" betrifft einen *verknüpften* Datensatz, der über ein Lookup- oder Master-Detail-Feld erreicht wird. Dieselbe Fehlerfamilie, entgegengesetztes Ziel. Wenn die ID in der Meldung der Datensatz ist, auf dem Sie Speichern geklickt haben, handelt es sich um die Object-id-Variante.

Warum kann ein Admin den Datensatz bearbeiten, ein Standardbenutzer aber erhält diesen Fehler?

Admins haben in der Regel "Modify All Data" oder "Modify All" auf dem Objekt, was Org-Weite Standardwerte, Sharing-Regeln und die Rollenhierarchie umgeht. Der Standardbenutzer wird durch Objektberechtigungen oder Sharing auf Datensatzebene blockiert. Reproduzieren Sie die Aktion immer angemeldet als (oder per "Login As") betroffener Benutzer, um sie einzugrenzen.

Der Benutzer hat Read-Zugriff auf den Datensatz — warum trotzdem unzureichende Zugriffsrechte beim Speichern?

Read reicht zum Schreiben nicht aus. Bearbeiten oder Löschen erfordert die Edit/Delete-Objektberechtigung *und* Lese-Schreib-Zugriff auf den Datensatz. Ein als "Read Only" freigegebener Datensatz (über eine Sharing-Regel, die Rollenhierarchie oder eine manuelle Freigabe) lässt sich öffnen, aber Änderungen können nicht gespeichert werden, was sich als unzureichende Zugriffsrechte beim Aktualisieren zeigt.

Kann ein gesperrter oder genehmigungspflichtiger Datensatz diesen Fehler verursachen?

Ja. Solange ein Datensatz durch einen aktiven Genehmigungsprozess (oder eine Apex-Sperre) gesperrt ist, können selbst Benutzer mit Schreibzugriff nicht speichern, bis er genehmigt, zurückgezogen oder entsperrt wird. Prüfen Sie, ob sich der Datensatz in einem Genehmigungsprozess befindet, bevor Sie den Berechtigungen nachgehen.