Mit diesem Beitrag beleuchten wir „Salesforce Record Sharing“ genauer und geben Ihnen einige Handlungsempfehlungen bei potentiellen Data Skews mit auf den Weg.

Salesforce Implementierungen bedeuten, sich mit dem Thema "Record Sharing" zu befassen, um sowohl bestmögliche Zugriffsmöglichkeiten als auch die Sichtbarkeit auf Datensätze für die User in Salesforce einzustellen. Salesforce Record Sharing kann allerdings schnell zu einer komplizierten Aufgabe werden, denn die Konfigurationsmöglichkeiten – bis hin zu programmatischen Sharing – sind vielfältig. Die Praxis zeigt, dass Salesforce Orgs oftmals nicht optimal eingerichtet sind. Dies führt entweder zu unnötig vielen Zugriffsrechten auf Datensätze oder im Gegenteil zu nicht sichtbaren Datensätzen für die User.

Bei jeder Salesforce Implementierung / Anpassung ist daher eine sorgfältig durchdachte Sharingarchitektur entscheidend, insbesondere bei umfangreichen und komplizierten Datensätzen, Hierarchien und Businessanforderungen.

Mit diesem Beitrag beleuchten wir das Thema "Salesforce Sharing" genauer und geben Ihnen einige Handlungsempfehlungen bei potentieller ungleichmäßiger Datenverteilung ("Data Skews") und langsamen Antwortzeiten ("Performance") mit auf den Weg.

1. Grundlagen des Datenzugriffs

Der Datenzugriff ("Data Access") in Salesforce wird in zwei Grundkategorien unterteilt:

  • Object-Level Access
  • Record-Level Access

Über Profile und Berechtigungssätz ("Permission Sets") werden Object-Level Access Berechtigungen wie "Read", "Create", "Edit" und "Delete" (CRED) eingestellt. Diese definieren, welche Berechtigungen der User für das jeweilige Objekt (z. B. Accounts, Opportunities, Leads oder Custom Objects) erhält. Hier können auch die Einstellungen "View All" beziehungsweise "Modify All" vorgenommen werden, welche dem User, Zugriff auf alle Datensätze des jeweiligen Objektes erlaubt.

Mit Record Level Access (oder "Sharing") wird definiert, auf welche Datensätze ein User zugreifen kann. Hierfür bietet Salesforce diverse Konfigurationsmöglichkeiten an:

  • Organisationsweite Standardeinstellungen (OWD)
  • Rollenhierachie (Role Hierarchy)
  • Regionshierarchie (Territory Hierarchy)
  • Freigaberegeln (Sharing Rules)
  • Teams
  • Manuelles Sharing
  • Programmatischen Sharing über APEX

Alle Sharing Funktionen in Salesforce beruhen auf einer Inhaberschaft-basierten Sharingarchitektur und werden von drei Schlüsselkomponenten definiert:

  • Datensatzinhaber (außer bei Detail Records in einer Master-Detail Beziehung). Der Datensatzinhaber hat immer Zugriff auf eigene Datensätze.
  • Object Sharing Tables, die festlegen, welche User und Gruppen Zugriff auf Datensätze erhalten sowie den jeweiligen Zugriffslevel und -grund.
  • Group Maintenance Tables, die den Usern Zugriff auf Datensätze über private und öffentliche Gruppen, Warteschlangen, Rollen- und Regionshierarchie gewähren.

2. Wie funktioniert Record Sharing in Salesforce genau?

Sharing Tables

Sofern die OWD (Organisation Wide Defaults) für ein Objekt auf "Privat" oder "Öffentlicher Lesezugriff" eingestellt sind, wird im Hintergrund für das jeweilige Objekt (Standard- oder Custom Objekt) ein verbundenes Share Objekt (Object Share Table) eingerichtet. In diesem Table wird festgelegt, welche Benutzer und Gruppen, Zugriff auf die Datensätze erhalten.

In der folgenden Abbildung wird der Share Table exemplarisch für das Objekt "Accounts" gezeigt:

  • Maria hat vollen Zugriff auf den Account "A1" weil sie die Datensatzinhaberin ist.
  • Frank hat "Read/Write" Zugriff auf den Account "A1" aufgrund eines manuelles Sharings durch Maria.
  • Die User aus der Gruppe "Strategie" haben "Read" Zugriff auf den Account "A1" aufgrund einer Freigaberegel (Rule) erhalten

Zusammenfassend werden alle User und Gruppen, die Zugriff auf Accounts haben, in den Account Sharing Table festgehalten.

Group Maintenance Tables

Wie oben beschrieben, gibt der Sharing Table an, welche User und Gruppen Zugriff auf den Datensatz haben. Die Informationen, welche User zu einer Gruppe gehören, wird in dem Group Maintenance Table verwaltet. Diese Tabelle speichert die Zugehörigkeit für alle Gruppen ab, wie z. ;B. Rollen, Rollen und nachgeordnete Positionen, Warteschlangen (Queues), Regionen, Regionen und nachgeordnete Positionen, Öffentliche Gruppen oder Private Gruppen. Nehmen wir ein einfaches Beispiel mit folgender Rollenhierarchie und einer Organisationsweiten Standardeinstellungen "Privat" für das Account Objekt.

In der folgenden Tabelle werden der Zugriff im Sharing Table und in der Group Maintenance Tabelle für das folgende Szenario dargestellt:

  • Peter (Rolle "Sales Mitarbeiter") ist Inhaber von Account "ACME"
  • Der "ACME" Account wird über eine Freigaberegel mit der Rolle "Service Manager Rollen und nachgeordnete Positionen" als "Read only" geteilt.

Die Zugriffsrechte ergeben sich nun hieraus:

  • Peter ist Accountinhaber und hat vollen Zugriff
  • Alex erbt die Berechtigung (vollen Zugriff) über die Rollen "Sales Manager" von Peter
  • Björn erbt die Berechtigung (vollen Zugriff) über die Rollen "Sales Manager" von Peter und bekommt zudem "Read only" Zugriff über die Rollen "Service Manager" von Vincent. Hierbei greift allerdings die "weiteste" Zugriffserlaubnis und Björn bekommt vollen Zugriff
  • Vincent erhält "Read only" Zugriff aufgrund der Freigaberegeln "Service Manager Rollen und nachgeordnete Positionen" und seiner Rolle "Service Manager"
  • Paul erhält "Read only" Zugriff aufgrund der Freigaberegeln "Service Manager Rollen und nachgeordnete Positionen" und seiner Rolle "Service Mitarbeiter"

3. Performance

Jedes Mal, wenn ein User einen Datensatz (z. B. Account) öffnet, einen Report ausführt, eine Listenansicht auswählt oder eine Suche durchführt, prüft Salesforce im Hintergrund die Zugriffsrechte anhand des Sharing Tables und Group Maintenance Table, ob der Account angezeigt werden darf oder nicht.

Gerade in Organisationen mit vielen Datensätzen, Hierarchieebenen oder Freigaberegeln, können die Antwortzeiten des Systems sehr langsam sein und über den Salesforce Benchmark von 300 Millisekunden liegen.

Szenario 1: Regelmäßige Neuordnung von Rollen oder Regionen

Wenn der Vertriebsprozess regelmäßige oder dynamische (Neu)Zuordnungen von Rollen und/oder Regionen vorsieht, kann es bei hohen Datenvolumen und granularen Hierarchien vorkommen, dass die Neuzuordnungen zu langen Berechnungszeiten führen und die Datensätze während der Neuberechnung blockiert sind.

Eine Optimierungsmöglichkeit ergibt sich, wenn die Datensätze direkt mit den Usern geteilt werden (z. B. über Account Teams), anstatt das Sharing über Rollen bzw. Regionen zu realisieren.

Szenario 2: Teilen von Datensätzen mit mehreren Usern

Braucht es jedoch viele User-Zugriffe auf einem Datensatz bei statischer Rollen- oder Regionenhierarchie, empfiehlt es sich, das Sharing über eine Gruppe (z. B. Rollen, Regionen oder öffentliche Gruppe) gegenüber dem individuellem Sharing zu realisieren. Somit lassen sich viele Einträge in dem Sharing Table verhindern – schließlich ist für Gruppen nur ein Eintrag in Sharing Table erforderlich.

Szenario 3: Ein User hat viele (> 10.000) Datensätze

Wenn ein User Inhaber sehr vieler Datensätze ist und einer Rolle zugeordnet wurde, können sehr langsame Systemantwortzeiten vorkommen. Hier ist es empfehlenswert, dem User entweder keine oder eine Rolle weiter oben in der Rollenhierachie zuzuweisen.

Ressourcen

Zurück zur Artikelübersicht

Teilen Sie diesen Artikel