Sharing Rules vs. Rollenhierarchie in Salesforce: der Unterschied

Rollenhierarchie und Sharing Rules sind die beiden Mechanismen, zu denen Admins am häufigsten greifen — und die beiden, die am häufigsten verwechselt werden. Beide erweitern den Zugriff auf Datensätze, aber in unterschiedliche Richtungen und aus unterschiedlichen Gründen. Den Unterschied richtig zu verstehen entscheidet darüber, ob du ein sauberes Sharing-Modell hast oder ein Geflecht aus sich überschneidenden Regeln.

Der Unterschied in einer Zeile

Rollenhierarchie — gewährt Zugriff automatisch und vertikal: Jeder, der im Organigramm über dem Datensatzinhaber steht, erbt dessen Zugriff.
Sharing Rules — gewähren Zugriff gezielt und horizontal: an Kollegen, andere Teams oder Gruppen, die die Hierarchie niemals verbinden würde, basierend auf Inhaberschaft oder Feldkriterien.

Beide setzen auf dem organisationsweiten Standard auf und können den Zugriff nur öffnen, niemals einschränken. (Die vollständige Schichtung findest du unter Wer kann einen Datensatz sehen.)

Rollenhierarchie: Zugriff fließt nach oben

Wenn für ein Objekt Grant Access Using Hierarchies aktiviert ist, erben Vorgesetzte automatisch den Zugriff auf Datensätze, die hierarchisch tiefer stehenden Nutzern gehören — oder mit ihnen geteilt sind. Keine Regel, keine Konfiguration pro Datensatz.

Beispiel. Ein organisationsweiter Standard „Privat” für Opportunities. Ein Vertriebsmitarbeiter besitzt einen Deal. Sein Vorgesetzter und dessen VP können den Deal automatisch sehen, weil sie in der Hierarchie über dem Mitarbeiter stehen. Das ist die Rollenhierarchie bei der Arbeit.

Das ist ideal für die Sichtbarkeit nach dem Prinzip Vorgesetzter-sieht-Team — und gleichzeitig die häufigste Quelle für „Warum können die das sehen?”-Überraschungen, weil niemand es pro Datensatz konfiguriert hat.

Sharing Rules erweitern den Zugriff quer durch die Hierarchie, an Nutzer, die das Organigramm getrennt hält. Es gibt zwei Varianten:

Auf Inhaberschaft basierend — teile Datensätze, die einer Gruppe gehören (Rolle, öffentliche Gruppe, Territory), mit einer anderen Gruppe.
Auf Kriterien basierend — teile Datensätze, die bestimmten Feldwerten entsprechen (z. B. Region = EMEA), mit einer Gruppe, Rolle oder einem Territory.

Beispiel. EMEA- und APAC-Vertrieb sind getrennte Zweige der Hierarchie, also sieht keiner die Deals des anderen. Eine kriterienbasierte Regel — Region = EMEA → Lesezugriff mit der Gruppe APAC Leadership teilen — öffnet genau diesen zweigübergreifenden Zugriff, ohne die Hierarchie anzutasten.

Wann was verwenden

Bedarf	Verwende
Vorgesetzte sehen die Datensätze ihres Teams	Rollenhierarchie
Zugriff folgt automatisch den Berichtslinien	Rollenhierarchie
Zwei gleichrangige Teams müssen die Datensätze des anderen sehen	Sharing Rule (auf Inhaberschaft basierend)
Datensätze teilen, die Feldkriterien entsprechen (Region, Typ, Phase)	Sharing Rule (auf Kriterien basierend)
Mit einer öffentlichen Gruppe oder einem Territory teilen	Sharing Rule
Einmaliger Zugriff auf einen einzelnen Datensatz	Manuelle Freigabe (keines von beiden)

Sie stapeln sich — und das ist der Haken

Weil der Zugriff additiv ist und die großzügigste Berechtigung gewinnt, kombinieren sich Rollenhierarchie und Sharing Rules. Ein Nutzer kann Zugriff auf einen Datensatz gleichzeitig über die Hierarchie und über zwei Sharing Rules erhalten. Keine davon setzt die anderen außer Kraft; eine einzige genügt.

Genau deshalb schleicht sich auch zu breiter Zugriff ein: Jede Regel wirkt für sich genommen sinnvoll, aber was ein Nutzer tatsächlich sieht, ist die Vereinigung aus Hierarchie + Regeln + manuellen Freigaben — und niemand hat dieses Gesamtbild im Kopf.

Keines von beiden schränkt ein — und das ist Absicht

Wenn du Zugriff reduzieren musst, helfen Sharing Rules und die Rollenhierarchie nicht weiter. Verschärfe den organisationsweiten Standard oder nutze Restriction Rules. Eine weitere Sharing Rule kann immer nur mehr Zugriff öffnen.

Den kombinierten Effekt sehen

Das Schwierige ist nicht der einzelne Mechanismus — es ist ihre Summe. Um zu wissen, warum ein Nutzer einen Datensatz sieht, musst du die Hierarchie und jede anwendbare Sharing Rule und manuelle Freigaben gemeinsam auswerten.

AgentForceAccess berechnet diese Vereinigung für dich: Frag, warum ein Nutzer einen Datensatz sehen kann, und es sagt dir, ob es an der Rollenhierarchie, an einer bestimmten Sharing Rule oder an beidem liegt — in klarem Deutsch, mit Angabe des jeweiligen Mechanismus.

Häufig gestellte Fragen

Was ist der Kernunterschied in einem Satz?

Die Rollenhierarchie öffnet den Zugriff nach oben und automatisch entlang der Berichtslinien, während Sharing Rules den Zugriff seitwärts und gezielt öffnen — für Nutzer, die eine Hierarchie niemals verbinden würde.

Wenn beide Zugriff auf denselben Datensatz gewähren könnten, was setzt sich durch?

Das spielt keine Rolle — der Zugriff in Salesforce ist additiv, und die großzügigste Berechtigung gewinnt. Gewährt entweder die Rollenhierarchie oder eine Sharing Rule den Zugriff, hat der Nutzer ihn. Du brauchst nie beide, die sich „einig" sein müssen.

Kann eine Sharing Rule Zugriff entziehen?

Nein. Sharing Rules und die Rollenhierarchie können den Zugriff nur über den organisationsweiten Standard hinaus erweitern. Um Zugriff zu reduzieren, änderst du den organisationsweiten Standard oder nutzt Restriction Rules — keine Sharing Rules.

Brauche ich noch Sharing Rules, wenn meine Rollenhierarchie gut aufgebaut ist?

In der Regel ja. Eine Hierarchie bildet nur vertikalen Zugriff ab — Vorgesetzte über ihre Mitarbeiter. Sobald zwei gleichrangige Teams oder eine Rolle in einem anderen Zweig die Datensätze des jeweils anderen sehen müssen, kann das nur eine Sharing Rule abbilden.