Implicit Sharing in Salesforce erklärt

Von allen Wegen, auf denen ein Salesforce-User einen Datensatz sehen kann, ist Implicit Sharing derjenige, den niemand konfiguriert und fast jeder vergisst. Es ist keine Regel, die du erstellst — es ist ein automatisches Verhalten, das fest in die Funktionsweise verknüpfter Datensätze eingebaut ist. Wer es versteht, eliminiert eine ganze Kategorie von “Aber das habe ich doch nie mit ihnen geteilt”-Überraschungen.

Was Implicit Sharing ist

Implicit Sharing ist Zugriff, den Salesforce automatisch gewährt, weil zwei Datensätze miteinander verknüpft sind — vor allem zwischen einem Account und seinen untergeordneten Datensätzen (Kontakte, Cases, Opportunities) sowie für Portal-/Community-User. Du richtest ihn nicht ein, er erscheint nicht als Sharing-Regel, und der größte Teil davon lässt sich nicht abschalten.

Es ist eine der Schichten im vollständigen Datensatzzugriffsmodell — und diejenige, die in der Vorstellung der meisten am häufigsten fehlt.

Die zwei Richtungen

Child-to-Parent: den Account hinter dem Datensatz sehen

Wenn ein User auf eine Opportunity, einen Case oder einen Kontakt zugreifen kann, gibt ihm Implicit Sharing lesenden Zugriff auf den übergeordneten Account dieses Datensatzes.

Die Logik dahinter ist praktisch: Du kannst eine Opportunity nicht sinnvoll bearbeiten, wenn du nicht siehst, zu welchem Account sie gehört. Also gewährt Salesforce den Account-Kontext stillschweigend — schreibgeschützt — jedem, der den untergeordneten Datensatz sehen kann.

Zugriff auf einen untergeordneten Datensatz → lesender Zugriff auf den übergeordneten Account. Automatisch.

Parent-to-Child: Account-Zugriff, der nach unten durchgreift

In die andere Richtung kann der Zugriff auf einen Account auch den Zugriff auf dessen untergeordnete Datensätze (seine Kontakte, Cases, Opportunities) ausweiten, gesteuert durch die Sharing-Einstellungen des Accounts. So ziehen Account-Ownership und Sharing auf Account-Ebene die verknüpften Datensätze mit sich.

Die genaue Lese-/Schreibstufe hängt von der Konfiguration ab, doch das Prinzip gilt: Account-Zugriff ist selten “nur der Account”.

Es ist (fast) immer schreibgeschützt

Das prägende Merkmal: Implicit Sharing ist leseorientiert. Der Child-to-Parent-Zugriff auf den Account ist schreibgeschützt. Kann ein User einen verknüpften Datensatz bearbeiten, dann kommt dieses Bearbeitungsrecht aus einem anderen Mechanismus — aus Ownership, der Rollenhierarchie oder einer Sharing-Regel — und nicht aus Implicit Sharing.

Implicit Sharing in Portal und Community

Experience-Cloud-/Portal-Szenarien bringen ihre eigenen Implicit-Sharing-Verhalten mit, damit externe User die verknüpften Datensätze sehen können, die sie benötigen (zum Beispiel ein Kunde, der die Cases und Kontakte zu seinem Account sieht). Dasselbe Muster gilt: automatisch, beziehungsgesteuert und nicht als Regel ausgedrückt, die du verwaltest.

Warum es der Zugriff ist, den man übersieht

Hier ist das Problem, das Implicit Sharing für Audits schafft:

• Es erscheint nicht als Sharing-Regel im Setup.
• Es ist nicht die Rollenhierarchie.
• Wenn du fragst “Mit wem haben wir das geteilt?”, lautet die ehrliche Antwort mit niemandem — es ist implizit.

Wenn ein User also einen Kontakt oder Account sehen kann, “der ihm nie gegeben wurde”, ist Implicit Sharing über einen verknüpften Datensatz ein Hauptverdächtiger — und es ist die Schicht, die manuelle Prüfungen überspringen. Das ist eine häufige Ursache hinter der Frage in Ein User sieht einen Datensatz, den er nicht sehen sollte.

Den Zugriff sichtbar machen, den niemand konfiguriert hat

Das Schwierige an Implicit Sharing ist genau, dass es nichts zum Anschauen gibt — keine Regel, kein Häkchen, nur eine Beziehung, die still lesenden Zugriff gewährt. Es über jeden verknüpften Datensatz hinweg von Hand zu rekonstruieren, ist nicht praktikabel.

AgentForceAccess berücksichtigt es automatisch: Wenn es erklärt, warum ein User einen Datensatz sehen kann, wird Implicit Sharing über einen verknüpften Account oder untergeordneten Datensatz wie jede andere Gewährung aufgezeigt und belegt — damit der Zugriff, den niemand konfiguriert hat, nicht länger der Zugriff ist, den niemand bemerkt.

Häufig gestellte Fragen

Was ist Implicit Sharing einfach erklärt?

Es ist eingebauter Zugriff, den Salesforce automatisch zwischen einem übergeordneten Account und dessen untergeordneten Datensätzen (Kontakte, Cases, Opportunities) sowie für Portal-/Community-User erstellt. Man richtet ihn nicht über eine Regel ein und kann ihn in der Regel auch nicht deaktivieren — er entsteht einfach, weil die Datensätze miteinander verknüpft sind.

Wenn ich eine Opportunity sehen kann, sehe ich dann auch ihren Account?

Ja. Child-to-Parent Implicit Sharing gibt dir lesenden Zugriff auf den übergeordneten Account jeder Opportunity, jedes Case und jedes Kontakts, auf die du zugreifen kannst — damit du den Kontext zum untergeordneten Datensatz hast. Den Account bearbeiten kannst du dadurch nicht.

Gewährt Implicit Sharing jemals Schreibzugriff?

Das Account-to-Child Implicit Sharing ist fast immer leseorientiert. Der Child-to-Parent-Zugriff auf den Account ist schreibgeschützt. Kann ein User einen verknüpften Datensatz bearbeiten, stammt dieses Bearbeitungsrecht aus einem anderen Mechanismus (Ownership, Rollenhierarchie, Sharing-Regel) und nicht aus Implicit Sharing.

Warum sorgt Implicit Sharing für Überraschungen beim Audit?

Weil im Setup nichts davon als Regel auftaucht. Der Sharing-Button des Datensatzes führt den Zugriff möglicherweise auf den verknüpften Datensatz zurück, und Admins, die Sharing-Regeln und die Rollenhierarchie prüfen, sehen eine implizite Gewährung schlicht nirgends aufgelistet — also wird genau dieser Zugriff übersehen.