Das Salesforce-Freigabemodell ist ein wesentliches Element für die Fähigkeit Ihrer Organisation, sicheren Zugriff auf Anwendungsdaten zu bieten. Daher ist es wichtig, dass Sie Ihr Freigabemodell richtig planen, um Ihre aktuellen und zukünftigen Datenzugriffsanforderungen zu erfüllen. In diesem Dokument werden Komponenten für den barrierefreien Zugriff auf Daten, Freigabemodellanwendungsfälle und echte Kundenfreigabelösungen beschrieben und einige Richtlinien zur Fehlerbehebung bereitgestellt.

Dieses Dokument ist für fortgeschrittene Systemadministratoren und Architekten vorgesehen. Zum Verstehen der Konzepte müssen Sie über ein funktionierendes Knowledge über das Salesforce-Sicherheits- und -Freigabemodell verfügen. Voraussetzungen für diesen Leitfaden sind:

• Salesforce-Hilfe: Freigabeeinstellungen
• Trailhead Modul: Datensicherheit
• Designing Record Access for Enterprise Scale (Entwerfen des Datensatzzugriffs für die Enterprise-Skala)
• Salesforce Gut durchdacht – sicher

Dieser Leitfaden konzentriert sich auf die Hauptfunktionen, die zum Steuern des Zugriffs auf Datensatzebene auf standardmäßige und benutzerdefinierte Objekte verwendet werden. In diesem Handbuch nicht behandelte Themen:

• Ordnerzugriff
• Inhaltszugriff
• Chatter-Zugriff
• Knowledge Base-Zugriff
• Ideen, Zugriff auf Fragen/Antworten
• Barrierefreier Zugriff auf mobile Daten

Mit der Sicherheit auf Datensatzebene können Sie Benutzern Zugriff auf einige Objektdatensätze erteilen, auf andere jedoch nicht. Wie bei den meisten Anwendungen beginnt der Datenzugriff mit einem Benutzer. Die Anwendung muss wissen, wer der Benutzer ist, bevor sie Zugriff erteilt. Bei Salesforce gibt es verschiedene Benutzertypen und manchmal ist die Zugriffsebene je nach Typ unterschiedlich. Statt jedes Attribut jedes Lizenztyps zu überprüfen, konzentrieren wir uns hier auf die interessanten Attribute, die sich erheblich auf den Datenzugriff auswirken. Datensatzinhaberschaft und uneingeschränkter Zugriff sind gleichbedeutend und austauschbar und bieten dem Benutzer die höchste Zugriffsebene auf einen Datensatz.

Benutzer mit hohem Volumen

Benutzer mit hohem Volumen (einschließlich Benutzer mit den Lizenztypen "Kunden-Community", "Kundenportal mit hohem Volumen" und "Authentifizierte Website") verwenden das Freigabemodell nicht, da ihre Lizenztypen keine Rollen unterstützen. Diese Lizenzen verfügen über ein eigenes Freigabemodell, das durch Fremdschlüsselübereinstimmung zwischen dem Benutzer (der Inhaber der Lizenz) und den Daten in Account- und Kontaktnachschlagevorgängen funktioniert. Administratoren können Freigabesets oder Freigabegruppen erstellen, um Benutzern mit hohem Volumen Zugriff auf Datensätze zu erteilen.

Externe Chatter Free- und Chatter-Lizenzen

Die Lizenzen "Chatter Free" und "Chatter External" folgen nicht dem Standardfreigabemodell. Diese Lizenzen haben keinen Zugriff auf CRM-Datensätze (standardmäßige oder benutzerdefinierte Objekte) und Inhaltsfunktionen und unterstützen keine Rollen. Daher erfolgt keine Freigabe.

Für den Rest dieses Dokuments wird von einem Salesforce-Benutzertyp ausgegangen, der ein vollständiges Freigabemodell verwendet. Weitere Informationen zu jedem verfügbaren Lizenztyp finden Sie unter Benutzerlizenzen.

Profile und Berechtigungssätze

Profile und Berechtigungssätze bieten Sicherheit auf Objektebene, indem sie bestimmen, welche Datentypen Benutzern angezeigt werden und ob sie Datensätze bearbeiten, erstellen oder löschen können. Bei jedem Objekt ignorieren die Berechtigungen "Alle anzeigen" und "Alle ändern" Freigaberegeln und -einstellungen, sodass Administratoren schnell Zugriff auf Datensätze erteilen können, die einem bestimmten Objekt in der gesamten Organisation zugeordnet sind. Diese Berechtigungen sind oft eine vorzuziehende Alternative zu den administrativen Berechtigungen "Alle Daten anzeigen" und "Alle Daten modifizieren", mit denen Benutzer alle Anwendungen und Daten anzeigen oder ändern können.

Profile und Berechtigungssätze steuern auch die Feldebenensicherheit, die die Felder in jedem Objekt bestimmt, auf die Benutzer zugreifen können. Beispielsweise kann ein Objekt 20 Felder aufweisen. Die Feldebenensicherheit kann jedoch so eingerichtet werden, dass den Benutzern fünf der 20 Felder nicht angezeigt werden.

Es wird dringend empfohlen, Berechtigungssätze und Berechtigungssatzgruppen anstelle von Profilen zu verwenden, um die Objektberechtigungen Ihrer Benutzer zu verwalten. Da Sie kleinere Berechtigungssatz-Bausteine wiederverwenden können, können Sie es vermeiden, Dutzende oder sogar Hunderte von Profilen für jeden Benutzer und jede Auftragsfunktion zu erstellen.

Datensatzinhaberschaft und Warteschlangen

Jeder Datensatz muss einem einzelnen Benutzer oder einer Warteschlange gehören. Der Inhaber hat basierend auf den Objekteinstellungen für das Profil des Inhabers Zugriff auf den Datensatz. Wenn das Profil des Inhabers beispielsweise über die Berechtigung "Erstellen" und "Lesen" für ein Objekt verfügt, jedoch nicht über die Berechtigung "Bearbeiten" oder "Löschen", kann der Inhaber einen Datensatz für das Objekt erstellen und den neuen Datensatz anzeigen. Der Inhaber kann den Datensatz jedoch nicht bearbeiten oder löschen. Benutzer, die sich weiter oben in einer Hierarchie (Rolle oder Region) befinden, übernehmen denselben Datenzugriff wie ihre nachgeordneten Mitarbeiter für Standardobjekte. Wenn der nachgeordnete Benutzer über Lesezugriff verfügt, gilt dies auch für die Benutzer, die in der Rollenhierarchie über ihm stehen. Dieser Zugriff gilt für Datensätze, deren Inhaber Benutzer sind, sowie für Datensätze, die für sie freigegeben wurden.

Mithilfe von Warteschlangen können Sie Datensätze priorisieren, verteilen und Teams zuweisen, die Arbeitslasten gemeinsam verwenden. Warteschlangenmitglieder und Benutzer, die in der Rollenhierarchie weiter oben stehen, können über Listenansichten auf Warteschlangen zugreifen und die Inhaberschaft von Datensätzen in einer Warteschlange übernehmen.

Wenn ein einzelner Benutzer Inhaber von mehr als 10.000 Datensätzen ist, sollten Sie wie folgt vorgehen:

• Der Benutzerdatensatz des Inhabers sollte keine Rolle in der Rollenhierarchie enthalten.

• Wenn der Benutzerdatensatz des Inhabers eine Rolle enthalten muss, platzieren Sie die Rolle oben in der Hierarchie in einem eigenen Zweig der Rollenhierarchie.

Weitere Informationen finden Sie unter Salesforce Well-Architected – Reliable.

Organisationsweite Standardeinstellungen

Organisationsweite Freigabeeinstellungen geben die Standardzugriffsebene an, über die Benutzer auf die Datensätze der jeweils anderen verfügen. Sie verwenden organisationsweite Freigabeeinstellungen, um Ihre Daten auf die restriktivste Ebene zu sperren. Verwenden Sie die anderen Sicherheits- und Freigabetools auf Datensatzebene, um anderen Benutzern selektiv Zugriff zu erteilen. Benutzer verfügen beispielsweise über Berechtigungen auf Objektebene zum Lesen und Bearbeiten von Opportunities und die organisationsweite Freigabeeinstellung lautet "Schreibgeschützt". Standardmäßig können diese Benutzer alle Opportunity-Datensätze lesen, jedoch nur bearbeiten, wenn sie Inhaber des Datensatzes sind oder über andere Berechtigungen verfügen.

Organisationsweite Standardeinstellungen können von einer Einstellung zu einer anderen geändert werden (Privat zu Gesteuert durch übergeordnetes Element, dann wieder zu Privat). Diese Änderungen erfordern jedoch eine Freigabeneuberechnung und können je nach Volumen zu langen Verarbeitungszeiten führen.

Nur für benutzerdefinierte Objekte können Sie die Einstellung Zugriff mithilfe von Hierarchien erteilen konfigurieren. Wenn dieses Kontrollkästchen deaktiviert ist (Standard ist aktiviert), wird verhindert, dass Benutzer, die in der Rollenhierarchie weiter oben stehen, den Zugriff übernehmen. Diese Einstellung befindet sich in den organisationsweiten Standardeinstellungen.

Rollenhierarchie

Eine Rollenhierarchie stellt eine Datenzugriffsebene dar, die ein Benutzer oder eine Gruppe von Benutzern benötigt. Die Rollenhierarchie stellt sicher, dass Manager unabhängig von den organisationsweiten Standardeinstellungen immer auf dieselben Daten wie ihre Mitarbeiter zugreifen können. Rollenhierarchien müssen nicht genau mit Ihrem Organigramm übereinstimmen. Stattdessen sollte jede Rolle in der Hierarchie eine Datenzugriffsebene darstellen, die ein Benutzer oder eine Gruppe von Benutzern benötigt.

In Salesforce-Organisationen, die in der Version Spring '21 oder höher erstellt wurden, können Sie bis zu 5.000 Rollen erstellen. In vor der Version Spring '21 erstellten Organisationen können Sie bis zu 500 Rollen erstellen und sich an den Salesforce-Kundensupport wenden, um diese Obergrenze zu erhöhen. Als bewährte Vorgehensweise sollten Sie die Anzahl der internen Rollen auf 25.000 und die Anzahl der externen Rollen auf 100.000 festlegen.

Als bewährte Vorgehensweise sollten Sie die Rollenhierarchie auf nicht mehr als 10 Ebenen von Verzweigungen in der Hierarchie festlegen.

Wenn sich die Rolle eines Benutzers ändert, werden alle relevanten Freigaberegeln ausgewertet, um bei Bedarf den richtigen Zugriff zu erhalten. Peers innerhalb derselben Rolle garantieren ihnen keinen Zugriff auf die Daten des jeweils anderen.

Die Modellierung der Rollenhierarchie beginnt mit dem Verständnis der Organisationsstruktur. Dies basiert in der Regel auf dem Verständnis des Umfangs eines Managers, beginnend von oben. Der CEO beaufsichtigt das gesamte Unternehmen. Der CEO verfügt in der Regel über direkte Unterstellte, die dann nach Geschäftseinheit (Vertrieb oder Support) oder geografischer Region (EMEA, APAC) segmentiert werden können. Diese Person verfügt dann über direkte Unterstellte, die weiter segmentiert werden könnten usw. Obwohl dies sehr nach einem HR-Organisationsdiagramm klingt, sollten Sie sich beim Modellieren des Datenzugriffs auf den barrierefreien Zugriff von Daten konzentrieren und die HR-Berichterstellung berücksichtigen.

Overlays sind immer der schwierige Teil der Hierarchie. Wenn sie sich in ihrer eigenen Zweigstelle befinden, benötigen sie Freigaberegeln, Teams oder die Regionsverwaltung, um Zugriff zu erhalten. Wenn sie in die Hierarchie aufgenommen werden, kann dies Auswirkungen auf die Berichterstellung haben.

Es ist wichtig, die Zeit mit dem Einrichten der Rollenhierarchie zu verbringen, da sie einer der grundlegenden Aspekte des Freigabemodells ist.

Öffentliche Gruppen

Eine öffentliche Gruppe ist eine Sammlung einzelner Benutzer, Rollen, Regionen usw., die alle eine gemeinsame Funktion haben. Öffentliche Gruppen können bestehen aus:

• Benutzer
• Kundenportalbenutzer
• Partnerbenutzer
• Rollen
• Rollen und interne nachgeordnete Positionen
• Rollen, interne und portalbezogene nachgeordnete Positionen
• Portalrollen
• Portalrollen und nachgeordnete Positionen
• Regionen
• Regionen und nachgeordnete Positionen
• Sonstige öffentliche Gruppen (Verschachtelung)

Gruppen können verschachtelt werden (Gruppe A in Gruppe B verschachtelt), es dürfen jedoch nicht mehr als fünf Ebenen verschachtelt werden. Die Berechnung der Gruppenmitgliedschaft hat Auswirkungen auf die Gruppenwartung und -leistung. Als bewährte Vorgehensweise sollten Sie die Gesamtzahl der öffentlichen Gruppen für eine Organisation auf 100.000 festlegen.

Inhaberbasierte Freigaberegeln

Inhaberbasierte Freigaberegeln ermöglichen Ausnahmen von organisationsweiten Standardeinstellungen und der Rollenhierarchie, die zusätzlichen Benutzern Zugriff auf Datensätze gewähren, deren Inhaber sie nicht sind. Inhaberbasierte Freigaberegeln basieren nur auf dem Datensatzinhaber.

Kontaktinhaberbasierte Freigaberegeln gelten nicht für private Kontakte oder Kontakte, die keinem Account zugeordnet sind.

Die Obergrenze der Gesamtfreigaberegeln pro Objekt beträgt 300.

Kriterienbasierte Freigaberegeln

Kriterienbasierte Freigaberegeln bieten Zugriff auf Datensätze, die auf den Feldwerten (Kriterien) des Datensatzes basieren. Wenn die Kriterien erfüllt sind (ein oder mehrere Feldwerte), wird ein Freigabedatensatz für die Regel erstellt. Die Datensatzinhaberschaft kommt nicht in Betracht.

Die Obergrenze für kriterienbasierte Freigaberegeln und Freigaberegeln für Gastbenutzer pro Objekt beträgt 50.

Freigaberegeln für Gastbenutzer

Bei einer Freigaberegel für Gastbenutzer handelt es sich um eine spezielle Art von kriterienbasierter Freigaberegel, die verwendet wird, um nicht authentifizierten Gastbenutzern Datensatzzugriff zu gewähren. Die Obergrenze für kriterienbasierte Freigaberegeln und Freigaberegeln für Gastbenutzer pro Objekt beträgt 50.

Warnung: Der Freigaberegeltyp für Gastbenutzer gewährt Gastbenutzern ohne Anmeldeinformationen Zugriff. Indem Sie eine Freigaberegel für Gastbenutzer erstellen, können Sie sofort und unbegrenzt auf alle Datensätze zugreifen, die den Kriterien der Freigaberegel entsprechen. Wenn Sie Ihre Salesforce-Daten schützen und Ihren Gastbenutzern Zugriff auf die benötigten Informationen erteilen möchten, sollten Sie alle Anwendungsfälle und Auswirkungen der Erstellung dieser Art von Freigaberegel berücksichtigen. Implementieren Sie Sicherheitssteuerungen, die Ihrer Meinung nach für die Vertraulichkeit Ihrer Daten geeignet sind. Salesforce ist nicht verantwortlich für die Offenlegung Ihrer Daten für nicht authentifizierte Benutzer aufgrund dieser Änderung gegenüber den Standardeinstellungen.

Manuelle Freigabe

Manchmal ist es unmöglich, eine konsistente Gruppe von Benutzern zu definieren, die Zugriff auf einen bestimmten Satz an Datensätzen benötigen. Datensatzinhaber oder andere Benutzer mit entsprechenden Berechtigungen, beispielsweise Systemadministratoren, können die manuelle Freigabe verwenden, um Benutzern Lese- und Bearbeitungsberechtigungen zu erteilen, die auf andere Weise keinen Zugriff haben. Die manuelle Freigabe ist nicht automatisiert, beispielsweise organisationsweite Freigabeeinstellungen, Rollenhierarchien oder Freigaberegeln. Sie bietet Datensatzinhabern jedoch die Flexibilität, Datensätze für Benutzer freizugeben, die sie anzeigen müssen.

Die manuelle Freigabe wird entfernt, wenn der Datensatzinhaber geändert wird oder wenn der gewährte Freigabezugriff keinen zusätzlichen Zugriff über die organisationsweite Freigabestandardzugriffsebene des Objekts hinaus gewährt. Dies gilt auch für manuelle Freigaben, die programmgesteuert erstellt wurden.

Manuelle Freigabedatensätze sind als Freigabedatensätze definiert, wobei die Zeilenursache auf "Manuelle Freigabe" festgelegt ist.

Alle Freigabedatensätze (Standardobjekte und benutzerdefinierte Objekte), deren Zeilenursache auf manuelle Freigabe festgelegt ist, können über die Schaltfläche Freigeben im Seitenlayout des Objekts bearbeitet und gelöscht werden, selbst wenn der Freigabedatensatz programmgesteuert erstellt wurde.

Teams

Ein Team ist eine Gruppe von Benutzern, die gemeinsam an einem Account, einer Vertriebs-Opportunity oder einem Kundenvorgang arbeiten. Datensatzinhaber können für jeden Datensatz, dessen Inhaber sie sind, ein Team erstellen. Der Datensatzinhaber fügt Teammitglieder hinzu und gibt die Zugriffsebene an, über die jedes Teammitglied für den Datensatz verfügt. Einige Teammitglieder können über Lesezugriff verfügen, während andere über Lese-/Schreibzugriff verfügen.

Nur Inhaber, Personen, die in der Hierarchie weiter oben stehen, und Administratoren können Teammitglieder hinzufügen und dem Mitglied mehr Zugriff gewähren. Ein Teammitglied mit Lese-/Schreibzugriff kann ein weiteres Mitglied hinzufügen, das bereits über Zugriff auf den Datensatz verfügt, dem das Team zugeordnet ist. Das Teammitglied kann ihm keinen zusätzlichen Zugriff gewähren.

Beim Erstellen eines Teammitglieds in der Anwendung werden zwei Datensätze erstellt: ein Teamdatensatz und ein zugehöriger Freigabedatensatz. Wenn Sie Teammitglieder programmgesteuert erstellen, müssen Sie den Teamdatensatz und den zugehörigen Freigabedatensatz verwalten. Pro Datensatz gibt es nur ein Team (Account, Opportunity oder Kundenvorgang). Wenn mehrere Teams benötigt werden, sollten Sie je nach Ihren spezifischen Anforderungen die Regionsverwaltung oder die programmgesteuerte Freigabe in Betracht ziehen.

Regionshierarchie

Bei Verwendung der Enterprise-Regionsverwaltung richten Sie eine Regionshierarchie ein, die die Regionsstruktur eines Modells anzeigt und als Hauptinteraktionspunkt fungiert. Wenn die Enterprise-Regionsverwaltung aktiviert ist, müssen Sie sowohl die Rollenhierarchie als auch die Regionshierarchie verwalten. Weitere Informationen finden Sie in der Salesforce-Hilfe unter Enterprise Territory Management (Enterprise-Regionsverwaltung).

Verwaltete Apex-Freigabe

Mit der verwalteten Apex-Freigabe (auch als programmgesteuerte Freigabe bezeichnet) können Sie Code verwenden, um komplexe und dynamische Freigabeeinstellungen zu erstellen, wenn eine Datenzugriffsanforderung auf andere Weise nicht erfüllt werden kann.

Wenn Sie einen Freigabedatensatz programmgesteuert erstellen und die vorkonfigurierte Zeilenursache (manuelle Freigabe) verwendet wird, können Sie diesen Freigabedatensatz über die Schaltfläche Freigeben in der Anwendung verwalten. Der Freigabedatensatz unterliegt allen Regeln mit der Ursache für die manuelle Freigabezeile, beispielsweise der Löschung bei der Inhaberübertragung.

Sie können auch Ihre eigenen Apex-Freigabegründe für benutzerdefinierte Objekte erstellen, um zu verfolgen, warum ein Datensatz mit einem Benutzer oder einer Gruppe von Benutzern erstellt wurde, und die Codierung zu vereinfachen, die erforderlich ist, um Aktualisierungen und Löschungen von Freigabedatensätzen vorzunehmen.

Weitere Informationen finden Sie unter Freigeben eines Datensatzes mit Apex, bevor Sie die programmgesteuerte Freigabe in Betracht ziehen.

Einschränkungsregeln

In Ihrer Datenzugriffskonfiguration möchten Sie möglicherweise verhindern, dass Benutzern Datensätze angezeigt werden, die sensible Daten enthalten können oder für ihre Arbeit einfach nicht wichtig sind. Sie können Einschränkungsregeln verwenden, damit Benutzer nur auf Datensätze zugreifen können, die die von Ihnen angegebenen Kriterien erfüllen. Wenn eine Einschränkungsregel auf einen Benutzer angewendet wird, werden die Datensätze, auf die der Benutzer über organisationsweite Standardeinstellungen, Freigaberegeln und andere Freigabemechanismen zugreifen kann, nach von Ihnen angegebenen Kriterien gefiltert. Einschränkungsregeln funktionieren in umgekehrter Weise wie die in diesem Thema diskutierten Freigabekomponenten. Statt Benutzern den Zugriff zu ermöglichen, schränken sie sie weiter ein.

Einschränkungsregeln sind für benutzerdefinierte Objekte, externe Objekte, Verträge, Ereignisse, Aufgaben, Arbeitszeitblätter und Arbeitszeitblatt-Einträge verfügbar. Sie können bis zu zwei aktive Einschränkungsregeln pro Objekt in der Enterprise und Developer Edition und bis zu fünf aktive Einschränkungsregeln pro Objekt in der Performance und Unlimited Edition erstellen. Einschränkungsregeln werden auf die folgenden Salesforce-Funktionen angewendet:

• Listenansichten
• Nachschlagevorgänge
• Themenlisten
• Berichte
• Suche
• SOQL
• SOSL

Implizite Freigabe

Die implizite Freigabe erfolgt automatisch. Sie können sie weder deaktivieren noch aktivieren – sie ist nativ in der Anwendung. Anders ausgedrückt, die implizite Freigabe ist keine konfigurierbare Einstellung. Es ist jedoch wichtig, dass jeder Architekt sie versteht. Die implizite Freigabe übergeordneter Elemente bietet Zugriff auf übergeordnete Datensätze (nur Account), wenn ein Benutzer Zugriff auf untergeordnete Opportunities, Kundenvorgänge oder Kontakte für diesen Account hat. Salesforce verfügt über eine Datenzugriffsrichtlinie, die angibt, ob ein Benutzer einen Kontakt (oder eine Opportunity, einen Kundenvorgang oder einen Auftrag) sehen kann, dann wird dem Benutzer implizit der zugehörige Account angezeigt. Bei der impliziten Freigabe untergeordneter Elemente wird dem Accountinhaber Zugriff auf die untergeordneten Datensätze eines Accounts gewährt. Dieser Zugriff wird in der Rolle des Inhabers in der Rollenhierarchie definiert. Die untergeordnete implizite Freigabe gilt nur für Kontakt-, Opportunity- und Kundenvorgangsobjekte (untergeordnete Objekte des Accounts). Die Zugriffsebenen, die bereitgestellt werden können, lauten Anzeigen, Bearbeiten und Kein Zugriff für jedes der untergeordneten Objekte, wenn die Rolle erstellt wird. Durch die Einstellung auf Anzeigen kann der Accountinhaber implizit die zugeordneten Objektdatensätze (Kontakt, Opportunity oder Kundenvorgang) anzeigen. Durch die Einstellung auf Bearbeiten kann der Accountinhaber das zugeordnete Objekt (Kontakt, Opportunity oder Kundenvorgang) implizit ändern.

Die implizite Freigabe gilt nicht für benutzerdefinierte Objekte.

Es gibt nicht ein Freigabemodell, das für alle Salesforce-Organisationen geeignet ist. Jede Organisation hat unterschiedliche Anforderungen und Herausforderungen, wenn es darum geht, das beste Freigabemodell zu entwickeln. Es ist wichtig, die am besten geeigneten Datenzugriffskomponenten zu verwenden, um die Freigabeanforderungen der Organisation zu erfüllen. Die folgenden Szenarien sind häufige Herausforderungen beim Erstellen eines Freigabemodells.

• Was geschieht mit der Rollenhierarchie?

  • In der Rollenhierarchie geschieht nichts, wenn Sie auch eine Regionshierarchie verwenden. Wenn Sie jedoch sowohl regionsbasierte Prognosen als auch rollenbasierte Prognosen zusammen verwenden, müssen Sie zwei Hierarchien verwalten. In diesem Fall wird empfohlen, die Rollenhierarchie zum Modellieren der HR-Berichtsstruktur und dann die Regionshierarchie zum Modellieren der tatsächlichen Vertriebshierarchie zu verwenden. Die Regionshierarchie eignet sich am besten zum Modellieren einer Matrixberichtsstruktur, bei der mehrere Manager unterstellt werden können.

    Wenn Sie die regionsbasierte Prognose und die rollenbasierte Prognose nicht zusammen verwenden, können Sie nur die Regionshierarchie als Vertriebshierarchie verwenden. In diesem Szenario ist es am besten, die Hierarchie so weit wie möglich zu vereinfachen oder zu vereinfachen.

    Es wird davon abgeraten, die Rollenhierarchie und die Regionshierarchie identisch zu machen, da dies zu unnötigen Freigabeaktivitäten führt.

• Können Sie weiterhin Teams verwenden?

  • Ja. Wenn Sie jedoch Ihre Zugriffsanforderungen innerhalb der Regionshierarchie (wie Overlays) erfüllen können, ist es besser, dies dort zu tun, als Teams zu verwenden. Sie pflegen bereits mehrere Hierarchien (Rolle und Region). Wenn Sie also versuchen, die Dinge so einfach wie möglich zu halten, implementieren Sie Teams nur, wenn keine andere vorhandene Freigabekomponente die Anforderung erfüllt.

• Neuausrichtung und Neuzuweisung

  • Es gibt zwei Arten von Änderungen: die Mitgliedschaft bei Rollen, Teams oder Regionen und die Struktur der Hierarchie. Mitgliedschaftsänderungen können in der Regel täglich, sogar stündlich, vorgenommen werden. Hierarchiestrukturänderungen (Neuausrichtungen) treten in der Regel seltener auf (vierteljährlich, halbjährlich oder jährlich) und können ressourcenintensiv sein. Zu berücksichtigen sind das Volumen der Änderungen und die Anzahl der kaskadierenden Änderungen, die jede Änderung hervorruft. Als Faustregel gilt, dass strukturelle Änderungen nicht mehr als vierteljährlich auftreten dürfen und alle Änderungen mit hohem Volumen (Massen- oder Massenänderungen) gut geplant, getestet und koordiniert werden.

• Große Datenmengen

  • Unabhängig davon, ob Sie für die anfängliche Einführung modellieren oder eine Änderung der Ausrichtung planen, müssen Sie das Datenvolumen ernsthaft berücksichtigen. Es gibt Schwellenwerte, bei denen die Leistung ein Faktor werden kann. Daher wird dringend empfohlen, Ihre Änderungen vor der Produktion in einer Sandbox zu testen. Diese Tests geben Ihnen auch eine Grundlage dafür an, wie lange die Änderung dauert.

    Wenn Sie über mehr als zwei Millionen Accounts verfügen und Teams oder die Enterprise-Regionsverwaltung implementiert haben, müssen Sie insbesondere auf die Leistung achten. Hierbei handelt es sich um komplexe Freigabemodellkomponenten, die für ein riesiges Volumen an Freigabedatensätzen und damit für langfristige Transaktionen sorgen können.

• Zurückstellen von Freigabeberechnungen

  • Wenn Sie über ein Objekt verfügen, das die Freigabe verwendet und über ein großes Volumen an Datensätzen verfügt (z. B. mehr als zwei Millionen Accounts) und eine Massenänderung vornehmen müssen (z. B. eine vierteljährliche Neuausrichtung, die eine Hierarchieänderung erfordert), dann gibt es eine Funktion, die der Salesforce-Kundensupport aktivieren kann, um automatische Freigabeberechnungen zurückzustellen. Jede einzelne Änderung an der Rollenhierarchie, Regionshierarchie, Gruppen, Freigaberegeln, Benutzerrollen, Teammitgliedschaft oder Inhaberschaft von Datensätzen kann nativ automatische Freigabeberechnungen initiieren. Wenn eine Massenänderung vorgenommen wird, beginnt eine Reihe automatischer Freigabeneuberechnungen. Indem Sie diese Neuberechnungen vorübergehend aussetzen, können Sie die Änderung vornehmen und dann Freigabeberechnungen gleichzeitig vornehmen. Diese Methode ist für Massenänderungen in der Regel effizienter und leistungsfähiger.

• Daten- und Inhaberschaftsverzerrungen

  • Datenverzerrungen sind als einige übergeordnete Datensätze mit vielen untergeordneten Datensätzen definiert. Diese Verzerrungen können Ihnen wirklich schaden, wenn einige Accounts viele Kontakte, Opportunities oder Kundenvorgänge aufweisen. Das Verhältnis, in dem die Leistungsverschlechterung beginnt, beträgt 1:10.000. Bewährte Vorgehensweise: Halten Sie das Verhältnis so nahe wie möglich an diesem (niedriger wird bevorzugt).

    Inhaberschaftsverzerrungen ähneln Datenverzerrungen, es sei denn, es handelt sich um einen einzelnen Benutzer, eine Rolle oder eine Gruppe, die Inhaber vieler Datensätze für ein Objekt ist. Wie bei Datenverzerrungen können auch diese zu langfristigen Transaktionen führen, was zu Leistungseinbußen bei Änderungen führen kann. Das empfohlene Verhältnis von Inhaber zu Anzahl der Datensätze beträgt ebenfalls 1:10.000.

    Wenn ein einzelner Benutzer Inhaber von mehr als 10.000 Datensätzen ist, sollten Sie wie folgt vorgehen:

    • Der Benutzerdatensatz des Inhabers sollte keine Rolle in der Rollenhierarchie enthalten.

    • Wenn der Benutzerdatensatz des Inhabers eine Rolle enthalten muss, platzieren Sie die Rolle oben in der Hierarchie in einem eigenen Zweig der Rollenhierarchie.

• Auswirkungen von Accounthierarchien auf den Datenzugriff

  • Viele Personen gehen bei der Implementierung einer Accounthierarchie von einer schlechten Annahme aus. Sie gehen davon aus, dass die Benutzer, die auf einen übergeordneten Account zugreifen können, auch auf die untergeordneten Accounts zugreifen können. Die einfache Tatsache, dass nur eine Über-/Unterordnungsbeziehung zwischen zwei Datensätzen besteht, steuert den Zugriff nicht. Obwohl die Rollenhierarchie und die Regionshierarchie auf diese Weise funktionieren, funktioniert dies in der Accounthierarchie nicht.

Sobald Sie Ihre Freigabemodellarchitektur abgeschlossen haben, werden Sie wahrscheinlich aufgefordert, einen Datensatz für einen Benutzer anzuzeigen. In der Regel hören Sie nicht, wann Benutzer etwas sehen können, was sie nicht sehen sollten. Bei Bedarf können Sie jedoch jeden Benutzer anzeigen, der Zugriff auf einen Datensatz hat und warum.

Die schwierigere und wahrscheinlich häufiger auftretende Herausforderung besteht darin, dass ein Benutzer einen Datensatz nicht anzeigen kann. Die von Ihnen erstellten Sicherheitsebenen bestimmen, wo Sie beginnen. Wenn Sie das Freigabemodell gut kennen, wissen Sie wahrscheinlich, welche Komponente den Zugriff hätte bereitstellen sollen, und können dort beginnen. Wenn Sie jedoch mit dem Freigabemodell weniger vertraut sind, beginnen Sie mit der Rollenhierarchie und ziehen Sie die einzelnen Ebenen zurück, um zu bestimmen, welche den Zugriff bereitstellen soll. Hier ein Flow zur Fehlerbehebung.

1. Überprüfen Sie, ob der Benutzer über Berechtigungen für den Zugriff auf das Objekt verfügt.
2. Identifizieren Sie die Rolle des Benutzers, der den Datensatz nicht anzeigen kann, und notieren Sie ihn sich.
3. Identifizieren Sie den Inhaber der Rolle des Datensatzes und notieren Sie sie sich.
4. Überprüfen Sie die Rollenhierarchie und überprüfen Sie, ob sich diese beiden Rollen in zwei verschiedenen Zweigen befinden (sollten sie sein).
5. Nun müssen Sie die Freigaberegeln für das Objekt überprüfen und sicherstellen, dass es keine Regel gibt, die dem Benutzer Zugriff erteilt. Suchen Sie bei Bedarf auch in öffentlichen Gruppen. Vielleicht wurde der Benutzer aus einer Gruppe ausgeschlossen, in der eine Freigaberegel vorhanden ist, oder es ist sinnvoll, eine neue Freigaberegel zu erstellen, um dem Benutzer Zugriff zu erteilen? Diese Auswahl hängt von der Architektur ab, die Sie pflegen möchten, und gilt für inhaberbasierte Freigaberegeln und kriterienbasierte Freigaberegeln.
6. Wenn Sie Teams verwenden, sollte dieser Benutzer für diesen Datensatz im Team sein? Wie werden Teams gepflegt und wie kam es zu dem Misserfolg?
7. Wenn die manuelle Freigabe verwendet wird, hat der Benutzer möglicherweise den Zugriff verloren, da sich der Datensatzinhaber geändert hat. Manuelle Freigaben werden verworfen, wenn sich die Inhaberschaft ändert. Die manuelle Freigabe hätte auch über die Schaltfläche Freigeben entfernt werden können.
8. Wenn Sie die Enterprise-Regionsverwaltung verwenden, fehlt der Benutzer in einer der Regionen? Wo wird die Mitgliedschaft in Regionen verwaltet und wie kam es zu dem Misserfolg? Oder der Datensatz wurde möglicherweise nicht der Region zugewiesen, in der der Benutzer Mitglied ist.
9. Wenn Sie programmgesteuerte Freigaben erstellen und Kriterien für die Freigabe im Code vorhanden sind, überprüfen Sie den Code, um zu verstehen, warum dieser Benutzer ausgelassen wurde.