"View All / Modify All" in Salesforce — die Umgehung im Blick

Der größte Teil des Salesforce-Sharing-Modells dreht sich darum, Datensatzzugriff sorgfältig zu gewähren. View All und Modify All werfen das über Bord — sie erlauben einem Benutzer, alles zu sehen oder zu ändern, und ignorieren das Sharing vollständig. Für Admins sind sie unverzichtbar und gefährlich, sobald sie sich ausbreiten. Hier erfahren Sie, was sie tun und wie Sie sie unter Kontrolle halten.

Was sie tatsächlich tun

Diese Berechtigungen umgehen das Sharing-Modell — Organisationsweite Standardeinstellungen, Rollenhierarchie, Sharing-Regeln, einfach alles:

• View All — jeden Datensatz eines Objekts sehen.
• Modify All — jeden Datensatz eines Objekts sehen, bearbeiten, löschen und übertragen.

Ein Benutzer mit View All auf Cases sieht jeden Case der Organisation, selbst bei einer privaten Organisationsweiten Standardeinstellung und ohne jede Sharing-Regel in Sicht. Das Sharing gilt für diesen Benutzer bei diesem Objekt schlichtweg nicht.

Wenn diese vorhanden sind, ist der Rest des Sharing-Modells irrelevant — sie stehen darüber.

Zwei Geltungsbereiche: Objekt vs. systemweit

Berechtigung	Geltungsbereich	Wirkung
View All (Objekt)	Ein Objekt	Alle Datensätze dieses Objekts sehen
Modify All (Objekt)	Ein Objekt	Volle Kontrolle über alle Datensätze dieses Objekts
View All Data	Gesamte Organisation	(Fast) alle Datensätze aller Objekte sehen
Modify All Data	Gesamte Organisation	Volle Kontrolle über (fast) alle Datensätze aller Objekte

Die Varianten auf Objektebene sind eingegrenzt und manchmal legitim. Das systemweite View All Data / Modify All Data ist die schwere Artillerie — mächtig und das, was am sorgfältigsten zu hüten ist.

Woher sie kommen

• Systemadministrator-Profil — wird standardmäßig mit View All Data und Modify All Data ausgeliefert.
• Benutzerdefinierte Profile und Berechtigungssätze — häufig vergeben, um einen Einzelfall zu lösen (“lass den Support einfach alle Cases sehen”), und dann vergessen.

Da die Berechtigungen eines Benutzers die Vereinigung seines Profils und jedes zugewiesenen Berechtigungssatzes sind, können sie sich in jedem von mehreren Berechtigungssätzen verstecken — und genau das macht sie so leicht aus dem Blick zu verlieren. Sie sind eng mit Profilen und Berechtigungssätzen verknüpft.

Warum sie das Erste sind, was man prüft, wenn der Zugriff falsch wirkt

Wenn ein Benutzer einen Datensatz sehen kann, den er nicht sehen sollte, zeigt die Schaltfläche “Freigabe” möglicherweise nichts an — weil der Zugriff gar nicht vom Sharing kommt. View All / Modify All gewähren Zugriff, ohne als Freigabe aufzutauchen. Bevor Sie sich also durch Sharing-Regeln wühlen, schließen Sie diese aus.

Warum sie für KI-Agenten doppelt zählen

Ein KI-Agent erbt die Berechtigungen seines ausführenden Benutzers. Trägt diese Identität View All Data, kann der Agent auf Anfrage jeden Datensatz der Organisation lesen — und umgeht damit jede Sharing-Regel, die Sie konfiguriert haben. Sicherzustellen, dass die Identität des Agenten frei von diesen Berechtigungen ist, ist ein zentraler Schritt beim Prüfen des Zugriffs vor der Bereitstellung.

Sie unter Kontrolle halten

• Inventarisieren Sie jedes Profil und jeden Berechtigungssatz auf View All/Modify All auf Objektebene und systemweites View All Data/Modify All Data.
• Listen Sie die Benutzer auf, die diese besitzen — direkt oder über Berechtigungssätze.
• Wenden Sie das Prinzip der minimalen Rechte an — ersetzen Sie pauschales View All überall dort durch eingegrenzte Sharing-Regeln, wo der Zugriff nicht wirklich organisationsweit sein muss.
• Prüfen Sie nach Änderungen erneut — ein neuer Berechtigungssatz kann eine Umgehung unbemerkt wieder einführen.

Die Umgehung automatisch sichtbar machen

Das Schwierige daran ist, dass diese Berechtigungen nicht dort auftauchen, wo man nach Sharing sucht — sie sind ein separater Schalter, in einem von vielen Berechtigungssätzen, der stillschweigend alles andere außer Kraft setzt. AgentForceAccess bezieht sie automatisch ein: Wenn erklärt wird, warum ein Benutzer (oder der Benutzer eines Agenten) einen Datensatz sehen kann, wird “er hat View All Data — Sharing gilt nicht” genauso klar dargestellt wie jede Sharing-Regel, sodass die Umgehung nicht länger das ist, was man übersieht.

Häufig gestellte Fragen

Was genau bewirken View All und Modify All?

Sie gewähren Zugriff auf jeden Datensatz eines Objekts und ignorieren dabei das Sharing-Modell. View All bedeutet, jeden Datensatz zu sehen; Modify All bedeutet, jeden Datensatz zu sehen, zu bearbeiten, zu löschen und zu übertragen. Die Varianten auf Objektebene gelten für ein Objekt; das systemweite "View All Data" und "Modify All Data" gelten für (fast) alle Objekte gleichzeitig.

Wer hat diese Berechtigungen standardmäßig?

Das Systemadministrator-Profil enthält View All Data und Modify All Data. Darüber hinaus tauchen sie in benutzerdefinierten Profilen und Berechtigungssätzen auf — oft hinzugefügt, um einen einmaligen Zugriffsbedarf zu lösen, und nie wieder entfernt. Prüfen Sie jedes Profil und jeden Berechtigungssatz, nicht nur die Administratoren.

Warum sind diese für KI-Agenten gefährlich?

Ein Agent erbt die Berechtigungen seines ausführenden Benutzers. Hat dieser Benutzer View All Data, kann der Agent auf Anfrage jeden Datensatz der Organisation lesen und umgeht damit das gesamte, sorgfältig konfigurierte Sharing. Stellen Sie vor der Bereitstellung eines Agenten sicher, dass seine Identität diese Berechtigungen nicht trägt.

Wie finde ich heraus, wer View All / Modify All hat?

Prüfen Sie jedes Profil und jeden Berechtigungssatz auf View All/Modify All auf Objektebene sowie auf das systemweite View All Data/Modify All Data und listen Sie anschließend die zugewiesenen Benutzer auf. Manuell ist das mühsam, weil die Berechtigung aus jedem der mehreren Berechtigungssätze stammen kann, die ein Benutzer besitzt.