Salesforce Blog

Salesforce Berechtigungen einfach erklärt

Profile, Rollen, Permission Sets oder Sharing Rules? Salesforce Berechtigungen können verwirrend sein. Um den Durchblick zu behalten erkläre ich die wichtigsten Begriffe. Mit einem gut eingestellten Berechtigungsmodell kann man viele Anwender glücklich machen und den Support im Griff behalten.

Das Berechtigungsmodell von Salesforce ist in vier Schritten eingeteilt. Beim Zugriff auf einen Datensatz prüft Salesforce die Berechtigungen je Schritt nacheinander ab. Diese Schritte sind:

1. Die Org-Berechtigung
2. Die Objektberechtigung
3. Die Datensatzberechtigung
4. Die Feldberechtigung

In diesem Beitrag gehe ich auf die Berechtigungen für ein Objekt und für einen Datensatz ein.

Der Unterschied zwischen Profil und Rolle

Profil und Rolle kann man schnell verwechseln. Dabei ist der Unterschied ganz einfach.
Profile gehören zu Berechtigungen für ein Objekt. Das ist, als ob man dem Anwender ein Werkzeug in die Salesforce Werkzeugkiste legt.
Rollen gehören zu Berechtigungen für einen Datensatz. Der Zugriff auf Datensätze ist eine Kiste von Werkstücken die der Anwender mit seinen Werkzeugen bearbeiten kann.
Also: Profil = Hammer und Rolle = Nagel. Um einen Nagel in die Wand zu schlagen benötigst Du beides. Profil (Hammer) und Rolle (Nagel).

Salesforce Berechtigungen: Objektberechtigungen

Der Anwender kann vier Werkzeuge für ein Objekt bekommen:

1. Read – Der Anwender darf Datensätze in einem Objekt anzeigen.
2. Create – Der Anwender darf Datensätze in einem Objekt erstellen.
3. Edit – Der Anwender darf Datensätze in einem Objekt bearbeiten.
4. Delete – Der Anwender darf Datensätze in einem Objekt löschen.

Daraus hat sich das Akronym CRED entwickelt. Auch andere Berechtigungen passen in das Bild der Werkzeugkiste. Beispielsweise die Möglichkeit einen Bericht auszuführen.

Berechtigungen in Salesforce folgen immer einem Muster: Zunächst wird die Berechtigung eingeschränkt. Dadurch erhält man einen gemeinsamen Nenner, der für möglichst viele Benutzer verwendet wird. Danach wird für ausgewählte Benutzer die Berechtigung wieder geöffnet.

Profile

Die wichtigste Stellschraube der Salesforce Berechtigungen ist das Profil. Jeder Benutzer kann und muss genau ein Profil haben. Bis zum Spring 20 Release galt die Aussage: Alles was ich einem Benutzer mit dem Profil erlaubt habe, kann ich ihm anschließend nicht wieder wegnehmen. Bei den Salesforce Berechtigungen ist das Profil auf der einschränkenden Seite der Objektberechtigungen.

Permission Sets

Auf der öffnenden Seite der Salesforce Berechtigungen gibt es das Permission Set. Dieses kann dem Anwender zusätzliche Werkzeuge (über das Profile hinaus) in die Werkzeugkiste legen. Jedem Anwender können beliebig viele Permission Sets zugeordnet werden.

Beispiel für Profile und Permission Sets

In einem Unternehmen gibt es die folgenden Anforderungen an die Salesforce Berechtigungen:

• Die Vertriebsmitarbeiter in einem Unternehmen sollen zwar Accounts lesen und bearbeiten, jedoch nicht anlegen oder löschen dürfen. Außerdem sollen sie Berichte zwar ausführen, allerdings nicht bearbeiten dürfen.
• Darüber hinaus gibt es im Vertriebsteam drei Key-User. Diese sollen zusätzlich Accounts anlegen und Berichte bearbeiten dürfen.

Lösung:
Als Salesforce Administrator konfigurieren wir ein Profil “Vertriebsmitarbeiter”. In diesem Profil fehlen die Werkzeuge Account erstellen und Account löschen. Zudem hat das Profil das Werkzeug “Bericht ausführen”. Alle Vertriebsmitarbeiter inklusive Key-Usern erhalten dieses Profil.
Außerdem konfigurieren wir ein Permission Set “Key-User”. Mit diesem Permission Set vergeben wir die Werkzeuge “Account erstellen” und “Bericht bearbeiten” zusätzlich an die drei Key-User.

Permission Set Groups

Mit dem Winter 20 Release hat Salesforce die Permission Set Groups eingeführt. Musste man bei den Salesforce Berechtigungen vorher jedem Benutzer die Permission Sets einzeln zuordnen, kann man jetzt mehrere Permission Sets zu einer Permission Set Group zusammenfassen. Das hört sich zunächst technisch an, hat aber weitreichende Auswirkungen. Salesforce wird die Berechtigungen über Profile irgendwann drastisch einschränken. In seinem Blog-Beitrag “Introducing The Next Generation of User Management: Permission Set Groups” gibt Sharon Liao einen Ausblick auf die Zukunft.

Über ein Muting Permission Set könnt ihr innerhalb einer Permission Set Group bestimmte Berechtigungen wieder ausblenden. Das bezieht sich aber nur auf die Berechtigungen in der Permission Set Group.

Teilt Eure Benutzer in Geschäftsfunktionen ein (ich würde es ja gerne Rolle nennen, aber die kommen später noch beim Datensatzzugriff). Beispielsweise Vertrieb, Buchhaltung oder HR. Anschließend erstellt Ihr für jede Geschäftsfunktion eine Permission Set Group.

Best Practices

Bei der Verwendung von Profilen und Permission Sets für die Salesforce Berechtigungen gibt es ein paar Best Practices:

1. Verwendet nicht die Standard-Profile von Salesforce. Diese lassen sich teilweise nicht anpassen und leider auch nicht löschen. Einzige Ausnahme: Das Systemadministrator Profil.
2. Verwendet so wenig wie möglich Profile. Wenn es ums Deployment geht, sind Profile das komplexeste Element in Salesforce. Ringt hartnäckig um jedes neue Profil.
3. Gebt über ein Profil nur die notwendigsten Berechtigungen. Nur das, was alle Benutzer einer größeren Einheit benötigen. Arbeitet lieber mit Permission Set Groups. Passt diese den Geschäftsfunktionen Eurer Benutzer im Unternehmen an.
4. Ein Profil benötigt Ihr nur noch für:
   1. Zuweisen von Page Layouts zu Benutzergruppen.
   2. Zuweisen von Lightning Record Pages zu Benutzergruppen.
   3. Festlegen von Standard Record Types für Benutzergruppen.
   4. Festlegen der Standard App für Benutzergruppen.
5. Versucht auf ein Muting Permission Set zu verzichten.

Salesforce Berechtigungen: Datensatzberechtigungen

Nachdem wir wissen, wie die Werkzeuge in die Werkzeugkiste des Anwenders kommen, wird es jetzt Zeit für die Werkstücke. Auch bei den Datensatzberechtigungen gibt es einschränkende und öffnende Stellschrauben.

Besondere Rechte des Datensatzbesitzers

Der Besitzer (Owner) eines Datensatzes hat besondere Rechte an diesen Datensatz. Diese Rechte kann man ihm nicht entziehen. Insofern ist die einzige Chance ihn daran zu hindern, “seinen” Datensatz zu bearbeiten: Nimm das Werkzeug zum Bearbeiten aus der Kiste. Sprich: Objektberechtigungen.

Für die Rechte des Besitzers könnt Ihr Euch das Akronym VESTD merken. Dieses steht für:

• V = View. Hat der Besitzer die Objektberechtigungen, kann er auf jeden Fall den Datensatz ansehen.
• E = Edit. Mit den Objektberechtigungen kann der Besitzer den Datensatz bearbeiten.
• S = Share. Der Besitzer eines Datensatzes kann diesen mit anderen Benutzern sharen. Beispielsweise ein Account Team Member in ein Account Team aufnehmen.
• T = Transfer Ownership. Der Besitzer eines Datensatzes kann einen anderen Benutzer als neuen Besitzer eintragen.
• D = Delete. Hat der Besitzer die Objektberechtigungen zum Löschen, kann er den Datensatz löschen.

Organisation Wide Defaults

Aus dem Bild wird schnell kar: Bei den Datensatzberechtigungen sind das Wichtigste die Organisation Wide Defaults (OWD). Diese können pro Objekt unterschiedlich sein. Also Beispielsweise für Accounts anders als für Opportunities. Bei den OWD gibt es drei Möglichkeiten:

1. Public Read/Write: Alle Anwender können alle Datensätze in einem Objekt sehen und bearbeiten (sofern sie die Objektberechtigungen haben).
2. Public Read Only: Alle Anwender können alle Datensätze in einem Objekt sehen. Jedoch können nur die Besitzer eines Datensatzes diesen auch bearbeiten.
3. Private: Nur die Besitzer eines Datensatzes können diesen sehen und bearbeiten.

Die Organisation Wide Defaults werden in größeren Salesforce Implementierungen oft auf private stehen.

Die Rollenhierarchie

Durch die Rollenhierarchie in Salesforce vererbt der Besitzer eines Datensatzes sein VESTD-Recht an einen Anwender in den übergeordneten Rollen. Für die Datensatzberechtigungen macht eine Rollenhierarchie erst dann Sinn, wenn die OWD wenigstens auf Public Read Only stehen. Stehen die OWD auf Public Read Write haben ohnehin alle Anwender Zugriff auf alle Datensätze eines Objekts.

Beispiel der Salesforce Berechtigungen für die Rollenhierarchie anhand von Opportunities

Das obige Diagramm zeigt ein Beispiel einer Rollenhierarchie. Falls die OWD für Opportunities auf Private stehen, gilt folgender Datensatzzugriff:

1. Jeder Vertriebsmitarbeiter kann nur seine eigenen Opportunities bearbeiten.
2. Die Vertriebsleiter können alle Opportunities ihres Vertriebsteams bearbeiten. Sie haben jedoch keinen Zugriff auf die Opportunities der anderen Vertriebsteams.
3. Die Geschäftsführung für den Vertrieb kann alle Opportunities bearbeiten.

Besonderheit bei der Definition der Rollenhierarchie

Legt man eine neue Rolle in Salesforce an, gibt es bis zu drei Optionen die man auswählen muss. Diese legen fest, welchen Zugriff ein Inhaber eines Accounts auf die Contacts, Opportunities und Cases dieses Accounts hat. Damit kann ein Administrator einem Accountinhaber die abhängigen Datensätze freigeben, auch wenn diese Datensätze dem Accountinhaber nicht gehören.

Wenn Salesforce nicht alle drei Optionen anzeigt, sind die OWD der fehlenden Objekte nicht auf “private” eingestellt.

Sharing Rules

Nachdem die Rollenhierarchie eingerichtet ist, helfen Sharing Rules beim lateralen Datensatzzugriff in Salesforce. Dabei gibt es zwei unterschiedliche Arten von Sharing Rules:

1. Owner Based Sharing Rules: Mit diesen Sharing Rules können wir Datensätze basierend auf den Datensatzbesitzer freigeben.
2. Criteria Based Sharing Rules: Mit diesen Sharing Rules können wir Datensätze basieren auf bestimmten Bedingungen des Datensatzes freigeben.

Der Mechanismus der Sharing Rules ist einfach. Zunächst wählt man, welche Datensätze man teilen möchte. Danach, mit wem man diese Datensätze teilen möchte. Anschließend, welches Zugriffsrecht man gewähren möchte.

Wichtig: Sharing Rules sind nicht dafür gedacht, Datensätze von und mit einzelnen Anwendern freizugeben. In den Auswahllisten gibt es nur die Möglichkeit Roles, Roles and Subordinates (Untergebene) sowie Public Groups auszuwählen. Seht ihr Sharing Rules, bei denen Datensätze einzelner Benutzer über eine Criteria Based Sharing Rule identifiziert werden, ist irgendwas schlecht konfiguriert.

Achtung: Sharing Rules sind Begrenzt. Pro Objekt dürft ihr maximal 300 Sharing Rules anlegen. Davon dürfen maximal 50 Criteria Based Sharing Rules sein.

Beispiel der Salesforce Berechtigungen für Sharing Rules anhand von Opportunities

Die Zugriffe auf Opportunities sollen im weiter oben stehenden Beispiel für die Rollenhierarchie erweitert werden. Zusätzlich zu den bereits bestehenden Zugriffsrechten soll:

1. Die Verkaufsleiter sollen alle Opportunities ansehen können, aber nur die Opportunities aus ihrem Gebiet (Nord, Süd, Mitte) bearbeiten.
2. Die Vertriebsmitarbeiter sollen die Opportunities aus ihrem Gebiet (Nord, Süd, Mitte) lesen können. Allerdings sollen sie nur ihre eigenen Opportunities bearbeiten können. Keinesfalls sollen sie Opportunities aus anderen Gebieten lesen können.

Um diese Anforderungen zu erfüllen, müssen wir neben der Rollenhierarchie sechs Owner Based Sharing Rules anlegen:

1. Teile alle Opportunities, die der Rolle “GF Vertrieb” und untergebenen gehören mit der Rolle “VL Nord” und gibt der Rolle Read Zugriff.
2. Teile alle Opportunities, die der Rolle “GF Vertrieb” und untergebenen gehören mit der Rolle “VL Mitte” und gibt der Rolle Read Zugriff.
3. Teile alle Opportunities, die der Rolle “GF Vertrieb” und untergebenen gehören mit der Rolle “VL Süd” und gibt der Rolle Read Zugriff.
4. Teile alle Opportunities, die der Rolle “Vertrieb Nord” gehören mit der Rolle “Vertrieb Nord” und gibt der Rolle Read Zugriff.
5. Teile alle Opportunities, die der Rolle “Vertrieb Mitte” gehören mit der Rolle “Vertrieb Mitte” und gibt der Rolle Read Zugriff.
6. Teile alle Opportunities, die der Rolle “Vertrieb Süd” gehören mit der Rolle “Vertrieb Süd” und gibt der Rolle Read Zugriff.

Die ersten drei Sharing Rules geben den Vertriebsleitern Lesezugriff auf alle Opportunities. Auf die Opportunities in ihrem Gebiet haben sie bereits Zugriff über die Rollenhierarchie. Da sie über die Rollenhierarchie das VESTD Recht der Besitzer erben, können sie die Opportunities in ihrem Gebiet auch bearbeiten. Vorausgesetzt sie haben das entsprechende Werkzeug über Profil oder Permission Set erhalten.

Die letzten drei Sharing Rules geben den Vertriebsmitarbeitern Lesezugriff auf die Opportunities der Kollegen in ihrem Gebiet.

Public Groups

Mit Public Groups könnt ihr mehrere Rollen zu einer Gruppe zusammenfassen. Sie sind nur ein Sammelbehälter für Anwender und haben keine eigene Funktion. Dadurch könnt ihr bei den Datensatzberechtigungen Sharing Rules sparen. In eine Public Group könnt ihr aufnehmen:

1. Roles
2. Roles and Subordinates
3. Andere Public Groups
4. Einzelne Anwender

Indem wir eine Public Group “Vertriebsleitung” erstellen, können wir die ersten drei Sharing Rules im obigen Beispiel durch eine einzige Sharing Rule ersetzen:

• Teile alle Opportunities, die der Rolle “GF Vertrieb” und untergebenen gehören mit der Public Group “Vertriebsleitung” und gibt der Public Group Read Zugriff.

Teams

Mit Hilfe von Teams kannst Du einzelne Datensätze für bestimmte Benutzer freigeben. Das Beste daran: Das kann ein Benutzer ohne Admin Support selbst machen. Als Administrator müssen wir nur die Teamrollen festlegen (Achtung: nicht verwechseln mit den Rollen der Rollenhierarchie). Salesforce unterstützt Teams bei drei Objekten:

1. Account mit AccountTeams
2. Opportunity mit OpportunityTeams
3. Case mit CaseTeams

Für jedes dieser Objekte können wir im Setup unterschiedliche Teamrollen definieren. Diese Teamrollen haben bei den Berechtigungen keine Funktion. Sie können allerdings in Workflows und Prozessen genutzt werden. Zum Beispiel könnt ihr allen AccountTeam Mitgliedern einer bestimmten Rolle eine Email senden.

Zunächst müsst ihr als Admin die Teamrollen definieren. Danach kann der der Besitzer eines Datensatzes (oder ein in der Rollenhierarchie über ihn stehender Benutzer) ein Teammitglied hinzufügen. Achtung: Falls ein Benutzer die Funktion nicht ausführen kann, fehlt ihm das S=Share von den VESTD Rechten. Das kann passieren, wenn er beispielsweise nur über eine Sharing Rule Zugriff zum Datensatz erhalten hat. Bei AccountTeams können Benutzer zusätzlich zum Zugriff auf den Account auch noch Zugriff auf Contacts, Cases und Opportunities des Accounts gewähren.

Manual Sharing

Falls Ihr einzelne Datensätze in einem Objekt freigeben wollt, das keine Teams unterstützt (z.B. Leads oder Opportunities), könnt ihr das Manual Sharing benutzen. Beim Manual Sharing könnt ihr Datensätze nicht nur mit einzelnen Benutzern teilen sondern auch mit Rollen, Rollen und nachgeordneten Positionen und Public Groups.

Territory Management

Falls die bisher vorgestellten Möglichkeiten der Salesforce Berechtigungen nicht genügen, könnt ihr das Enterprise Territory Management aktivieren. Dadurch erhaltet ihr die Möglichkeit, eine Hierarchie von Territories anzulegen. Einerseits können das geografische Gebiete sein. Andererseits könnt ihr damit auch Branchen abbilden. Falls ihr einen Matrixvertrieb habt, kann ein Kunde sowohl in einem geografischen Gebiet, wie auch in einer speziellen Branche sein. Er wird dann von zwei unterschiedlichen Vertriebsmitarbeitern angesprochen.

Im Gegensatz zur Rollenhierarchie könnt ihr einen Benutzer mehreren Territories zuweisen. Ebenso könnt ihr einen Account mehreren Territories zuweisen. Zusammen mit der Territory Hierarchie könnt ihr sehr flexibel den Zugriff auf Accounts und Opportunities steuern.

Achtung: Es gibt in Salesforce sowohl ein Territory Management wie auch ein Enterprise Territory Management. Das “normale” Territory Management ist alt und wird mit dem Summer 21 Release deaktiviert.

Update Winter 22: Restriction Rules

Mit dem Winter 22 Release führt Salesforce die Restriction Rules ein. Sie schränken den Zugriff auf Datensätze wieder ein, nachdem der Zugriff vorher durch OWD, Rollen, Sharing Rules, Teams, Manual Sharing oder Territorry Management gewährt wurde. Restriction Rules gibt es allerdings nicht für alle Objekte. Es gibt sie nur für Contracts, Tasks, Events und alle Custom Objects.

Mit Restriction Rules kannst Du Datensätze, die ein bestimmtes Kriterium erfüllen, vor einem Anwender verstecken. Als Beispiel kannst Du Dir Tasks am Account vorstellen. Normalerweise sehen alle Anwender alle Tasks an einem Account, falls sie Zugriff auf den Account haben. Möchtest Du, dass Deine Vertriebsmitarbeiter die Tasks vom Service nicht sehen, kannst Du das mit einer Restriction Rule verhindern.

Best Practices

Bei den Salesforce Berechtigungen für den Datensatzzugriff solltet ihr folgendes beachten:

1. Weist jedem Benutzer eine Rolle zu. Die Rollenhierarchie wird nicht nur beim Datensatzzugriff sondern auch beim Reporting verwendet.
2. Fügt nur Rollen oder Rollen und nachgeordnete Positionen in eine Public Group. Vermeidet es, einzelne Benutzer hinzu zu fügen. Das erspart Euch eine aufwändige pflege.
3. Bevor ihr mit Public Groups beginnt, versucht zuerst, ob die Rollenhierarchie genügt. Sie muss nicht dem Organigramm entsprechen.
4. Verwendet so wenig wie möglich Automatisierungen für die Berechtigungsvergabe. Sonst gibt es schnell einen Mixed DML Operation Fehler.

Salesforce Berechtigungen: Das könnte Dich auch interessieren

• In unseren Salesforce Seminaren ADX201 und ADX211 bringen wir Dir die Feinheiten im Detail bei.
• Du möchtest Dein Berechtigungsmodell überarbeiten? Unser Salesforce Consulting optimiert Dein Berechtigungsmodell.