So beheben Sie INSUFFICIENT_ACCESS_OR_READONLY bei Salesforce-Deployments

Der Benutzer, der das Deployment oder den Datenimport ausführt, hat keine Berechtigung zum Erstellen, Bearbeiten oder Löschen des betroffenen Objekts oder Felds.

Tritt auf bei: Laufzeit-DML, bei Datenimporten, API-Aufrufen und Apex-Tests

Was das bedeutet

INSUFFICIENT_ACCESS_OR_READONLY bedeutet, dass das Profil oder der Permission Set des ausführenden Benutzers nicht die Zugriffsstufe gewährt, die der Vorgang benötigt, meist Feldsicherheit oder Objekt-CRUD-Berechtigungen in der Ziel-Org. Das unterscheidet sich von INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, das einen referenzierten Datensatz betrifft statt das direkt beschriebene Objekt.

Dies ist der Direktobjekt-Fall: Der Datensatz oder das Feld, in das die DML-Anweisung schreibt, ist genau das, worauf der ausführende Benutzer keinen Zugriff hat, nicht ein verwandter, unterwegs berührter Datensatz.

Diagnose

Häufige Ursachen

Profil des Integrations- oder Deployment-Benutzers fehlt die Objektberechtigung
Das Profil des API- oder CI-Benutzers hat nur Lesezugriff oder keinen Zugriff auf das Objekt, oft weil es aus Sicherheitsgründen eng gefasst wurde.
Feldsicherheit blendet das Feld für dieses Profil aus
Die Objektberechtigung besteht, aber ein bestimmtes Feld ist für das Profil oder den Permission Set des ausführenden Benutzers auf unsichtbar oder schreibgeschützt gesetzt.
Permission Set wurde in der Ziel-Org nicht deployt oder zugewiesen
Ein Permission Set, das den benötigten Zugriff gewährt, existiert in der Versionsverwaltung, wurde aber nicht deployt und dem Deployment-Benutzer in der Ziel-Org zugewiesen.

Die Lösung

  1. Objekt- und Feldberechtigungen für den Deployment-Benutzer gewähren
    Aktualisieren Sie das Profil oder den Permission Set des Deployment- oder Integrationsbenutzers, sodass es die erforderliche Objekt-CRUD- und Feldsicherheit enthält.
  2. Fehlende Permission Sets deployen und zuweisen
    Fügen Sie die Permission-Set-Metadaten dem Deployment hinzu und bestätigen Sie, dass sie dem ausführenden Benutzer in der Ziel-Org zugewiesen sind, nicht nur in der Quelle.
    sf org assign permset --name Integration_Data_Access --target-org myOrgAlias
  3. Einen dedizierten Integrationsbenutzer mit stabilem Permission Set verwenden
    Standardisieren Sie Deployment- und API-Zugriff auf einen dafür gebauten Benutzer und Permission Set statt auf das Konto eines einzelnen Admins, das sich ändern kann.
In der Praxis

Wie Serpent das verhindert

Serpent verwaltet die Permission Sets, die es CI- und Integrationsbenutzern pro Org zuweist, sodass Zugriffslücken zwischen Umgebungen als Task-Blocker sichtbar werden statt als fehlgeschlagener Pipeline-Lauf. Siehe die Bibliothek der Salesforce-Deployment-Fehler.

Freigabe- und Audit-Nachverfolgbarkeit in Serpent

Prävention

Die Permission-Set-Zuweisung zusammen mit dem Permission Set selbst deployen
Fügen Sie PermissionSetAssignment-Metadaten in dasselbe Deployment wie einen neuen Permission Set ein, damit der Zugriff tatsächlich in der Ziel-Org ankommt, nicht nur die Definition.
Zugriff des Integrationsbenutzers bei jedem neuen Feld überprüfen
Machen Sie die Feldsicherheitsprüfung für den Permission Set des dauerhaften Integrationsbenutzers zu einem Checklistenpunkt bei jeder Schemaänderung, nicht zu einem nachträglichen Gedanken.
Niemals einen persönlichen Admin-Login für geplante Integrationen teilen
Persönliche Konten werden deaktiviert, MFA ändert sich, und Passwörter werden zurückgesetzt; ein dedizierter Integrationsbenutzer mit verwaltetem Permission Set vermeidet alle drei Fehlerquellen.
Häufige Fragen

INSUFFICIENT_ACCESS_OR_READONLY, beantwortet

Warum funktioniert dasselbe Deployment für einen Admin, schlägt aber für den CI-Benutzer fehl?
Der CI- oder Integrationsbenutzer hat fast immer ein engeres, stärker eingeschränktes Profil als ein Admin. Vergleichen Sie dessen Objekt- und Feldzugriff mit dem, was das Deployment tatsächlich beschreibt.
Setzt sich ein Permission Set gegenüber einer restriktiveren Profileinstellung durch?
Bei Objekt- und Feldberechtigungen ja; ein Permission Set kann zusätzlichen Zugriff über das Profil hinaus gewähren, aber nicht mehr, als die Lizenz- und Funktionsgrenzen der Org insgesamt zulassen.
Bedeutet READONLY im Fehlernamen, dass es sich um ein Formelfeld handelt?
Nicht zwangsläufig. Es bedeutet meist, dass die Feldsicherheit des Benutzers für ein gewöhnliches bearbeitbares Feld auf schreibgeschützt gesetzt ist, kann aber auch für tatsächlich nicht beschreibbare Felder wie Formeln gelten.

Kostenlos starten. Keine Kreditkarte, keine Installation, keine Verpflichtung.

In unter 15 Minuten eingerichtet. Keine DevOps-Fachkraft nötig.

Neugierig auf schnelleres Shipping, bevor Sie einsteigen? Sprechen wir

Unverbindlich.