Die Salesforce Sharing Architecture ist ein wesentlicher Baustein für den sicheren Zugriff auf Anwendungsdaten im Unternehmen. Es ist enorm wichtig und entscheidend, dass das Freigabe- bzw. Sharing-Model richtig gestaltet wird, um den aktuellen und künftigen Anforderungen am Datenzugriff gerecht zu werden.

In diesem Beitrag werden die einzelnen Komponenten der Salesforce Sharing Architecture für den Datenzugriff beleuchtet. Zudem zeigen wir einige Anwendungsfälle und Kundenszenarien auf. Abschließend erhalten Sie noch einen Leitfaden, mit dem sich die Fehlersuche vereinfachen lässt.

Inhaltsverzeichnis

  1. Lizenzen
  2. Die Salesforce Sharing Architecture Komponenten
  3. Profile & Berechtigungssätze
    1. Standard Profile
    2. Feldebenensicherheit
  4. Datensatzinhaber & Warteschlangen
  5. Organisationsweite Freigabestandardeinstellungen
  6. Rollenhierarchie
  7. Öffentliche Gruppen
  8. Freigaberegeln
    1. Datensatzinhaber-Freigaberegeln
    2. Kriterienbasierte-Freigaberegeln
    3. Manuelle Freigabe für Benutzerdatensätze
  9. Teams
  10. Regionshierarchie
    1. Freigaberegeln für Accountregionen
  11. Programmgesteuerte-Freigaben
  12. Implizite-Freigaben

I. Lizenzen

Eine Benutzerlizenz legt die grundlegenden Funktionen fest, auf die der Benutzer zugreifen kann. Jedem Benutzer ist genau eine Lizenz zugewiesen. Zusätzlich kann über ein Profil und / oder über BerechtigungssätzePermission-Sets der Zugriff auf die Daten gesteuert werden.

Salesforce bietet folgende Lizenztypen an:

  • Standard User Licenses
    • Für die Benutzer, die vollen Zugriff auf Standard-CRM und Salesforce AppExchange-Anwendungen benötigen. Benutzer mit dieser Lizenz haben Zugriff auf jede Standard- oder benutzerdefinierte Anwendung.
  • Chatter User Licenses
    • Salesforce bietet ebenfalls Chatter-spezifische Lizenzen an: Chatter External, Chatter Free und Chatter Only (Chatter Plus).
  • Communities User Licenses
    • Salesforce verfügt über drei unterschiedliche Community-Lizenzen für externe Benutzer: Customer Community, Customer Community Plus und Partner Community.
  • Service Cloud Portal User Licenses
    • Mit dieser Lizenz erhalten Ihre Kontakte unbegrenzte Logins für Ihr Service Cloud Portal, um auf Kundensupport-Informationen zugreifen zu können.
  • Sites and Site.com User Licenses (nur für Salesforce Classic)
    • Diese Lizenz ist für öffentliche Benutzer, die auf Ihre Site.com oder Salesforce-Sites Zugriff benötigen. Die Besucher der Sites haben Zugang zu allen Informationen, die auf einer aktiven, öffentlichen Website zu Verfügung gestellt werden.
  • Authenticated Website User Licenses
    • Benutzer des Plattform-Portals haben die Lizenz für die Website, die für die Verwendung mit Lightning Platform Sites entwickelt wurde. Es gibt den Benutzern benannter Sites unbegrenzte Logins für Ihr Plattform-Portal, um auf Kunden-Support-Informationen zuzugreifen.

Zurück nach oben

II. Die Salesforce Sharing Architecture Komponenten

Salesforce Sharing Architecture
Salesforce Sharing Architecture

Zurück nach oben

III. Profile & BerechtigungssätzePermission-Sets

Profile und BerechtigungssätzePermission-Sets bieten die notwendige Sicherheit auf der Objektebene. Sie legen fest, welche Datentypen die Benutzer sehen und ob sie Datensätze bearbeiten, erstellen oder löschen können.

Benutzer können immer nur ein Profil haben, aber je nach Salesforce Edition mehrere BerechtigungssätzePermission-Sets. Diese erweitern die Rechte des Nutzers, ohne das eigentliche Profil zu ändern.

In einem BerechtigungssatzPermission-Set können nur Berechtigungen vergeben werden, die über die eingestellte Lizenz freigegeben sind. Beispielsweise könnte einem User mit der Salesforce Plattform User Lizenz nicht die Berechtigung „Author Apex“ zugewiesen werden, da dieses Recht in dem Lizenztyp generell nicht zulässig ist.

Zusätzliche Info

  • Die Berechtigungen „View All“ und „Modify All“ ignorieren die FreigaberegelnSharing Rules und FreigabeeinstellungenSharing Settings, so dass schnell Zugriff auf Datensätze gewährt werden kann, die mit einem bestimmten Objekt in der gesamten Organisation verknüpft sind. Diese Berechtigungen sind oft eine bessere Alternative zu den administrativen Berechtigungen „View All Data“ und „Modify All Data“.

Zurück nach oben

1. Standard Profile

Jede Organisation enthält vordefinierte Standardprofile, die Sie Benutzern zuordnen können. Je nach Edition stehen unterschiedliche Profile zur Verfügung.

Hier eine Liste der am meisten genutzten Profile:

  • System Administrator
  • Standard Platform User
  • Standard Platform One App User
  • Standard User
  • Customer Community User
  • Customer Community Plus User
  • Partner Community User
  • Customer Portal User
  • High Volume Customer Portal
  • Authenticated Website
  • Customer Portal Manager
  • Partner User
  • Solution Manager
  • Marketing User
  • Contract Manager
  • Read Only
  • Chatter Only User
  • Chatter Free User
  • Chatter External User
  • Chatter Moderator User
  • Site.com Only User

Zurück nach oben

2. FeldebenensicherheitField-Level Security

Profile und BerechtigungssätzePermission-Sets steuern auch die FeldebenensicherheitField-Level Security, die in jedem Objekt festlegt, auf welche Felder die Benutzer zugreifen können bzw. dürfen.

Hierbei können die folgenden Funktionen eingeschränkt werden:

  • Detail und edit pages
  • Related lists
  • List views
  • Reports
  • Connect Offline
  • Email and mail merge templates
  • Custom links
  • The partner portal
  • The Salesforce Customer Portal
  • Synchronized data
  • Imported data

Die Felder, die Benutzer auf Detail- und Bearbeitungsseiten sehen, sind eine Kombination aus Seitenlayouts und FeldebenensicherheitField-Level Security. Es gelten immer die Feldzugriffseinstellungen, mit den meisten Einschränkungen. Es kann z.B. ein Feld geben, das in einem Seitenlayout als erforderlichrequired gesetzt ist, aber in der FeldebenensicherheitField-Level Security auf schreibgeschütztread-only. Die FeldebenensicherheitField-Level Security hat in diesem Beispiel die höhere Priorität ggü. dem Seitenlayout, so dass das Feld schreibgeschützt bleibt.

FeldebenensicherheitField-Level Security kann auf zwei Arten definiert werden:

  • Für mehrere Felder in einem einzigen BerechtigungssätzePermission-Sets oder dem Profil
  • Für ein einzelnes Feld auf allen Profilen

Zusätzliche Info

  • Die FeldebenensicherheitField-Level Security verhindert nicht die Suche nach den Werten in einem Feld.
  • Rollup-Zusammenfassungs-Roll-up Summary und FormularfelderFormula Fields sind auf Detailseiten schreibgeschützt und auf den Bearbeitungsseiten nicht verfügbar. Sie können allerdings für Benutzer sichtbar sein, obwohl sie Felder referenzieren, die Ihre Benutzer nicht sehen können.
  • Universell erforderliche FelderUniversally Required Fields erscheinen auf den Bearbeitungsseiten, unabhängig von der FeldebenensicherheitField-Level Security.

Zurück nach oben

IV. DatensatzinhaberRecord Ownership & WarteschlangenQueues

Jeder Datensatz muss entweder einen einzelnen Benutzer oder eine WarteschlangeQueue als Inhaberowner haben. Der Zugang des Inhabers wird über die Einstellungen des jeweiligen Benutzerprofils sicher- bzw. hergestellt. Beispielsweise, wenn das Profil des Eigentümers die Berechtigung zum Erstellencreate und Lesenread auf das Objekt hat, aber keine Berechtigung zum Bearbeitenedit oder Löschendelete, dann kann der Eigentümer einen Datensatz für das Objekt erstellen und diesen dann auch sehen. Allerdings ist der Eigentümer dann für diesen Datensatz nicht zum Editieren oder Löschen berechtigt. Benutzer, die in der Hierarchie (Rolle oder RegionTerritory) höher stehen, erhalten die gleichen Berechtigungen für Standard-Objekte, wie die ihnen untergeordneten Mitarbeiter. Falls diese nur Lese-Zugriff haben, dann gilt das auch für die Manager – also klassischer Bottom-Up-Ansatz. Dieser Zugang gilt sowohl für Datensätze, für die die Benutzer verantwortlich sind, als auch für geteilte Datensätze.

Mit Hilfe von WarteschlangenQueues können Datensätze priorisiert, verteilt und an Teams zugewiesen werden. Die Mitglieder der WarteschlangenQueues und Benutzer, die in der Hierarchie höher stehen, können über Listenansichten auf Datensätze zugreifen und die Verantwortung übernehmen.

Falls ein einzelner Nutzer für mehr als 10.000 Datensätze verantwortlich ist, haben sich folgende „Best Practices“ bewährt:

  • Das Benutzerprofil des für den Datensatz verantwortlichen Benutzers sollte keine Rolle im Rahmen der Rollenhierarchie ausüben.
  • Falls das Benutzerprofil doch über eine Rolle verfügen muss, sollte diese an der Spitze der Rollenhierarchie für seine jeweilige Ebene stehen.

Zurück nach oben

V. Organisationsweite FreigabestandardeinstellungenOrganization Wide Defaults

Die organisationsweiten Freigabeeinstellungen legen die Standardzugriffsebene für alle Benutzer fest. Hiermit lassen sich Daten auf der restriktivsten Ebene sperren. Um die Freigabe auf Datensatzebene zu erteilen, müssen andere Sicherheits- und Freigabetools genutzt werden.

Beispiel:
Die Benutzer verfügen über Berechtigungen auf Objektebene, um Opportunities zu lesen und zu bearbeiten. Die organisationsweiten FreigabeeinstellungenOrganization Wide Defaults sind schreibgeschützt. Mit dieser Einstellung können diese Benutzer alle Opportunity-Datensätze lesen, aber keine bearbeiten. Es sei denn, der Benutzer ist der Besitzer des Datensatzes oder hat bereits zusätzliche Berechtigungen erhalten. Organisationsweite Vorgaben sind die einzige Möglichkeit, den Benutzerzugriff auf einen Datensatz einzuschränken.

Für benutzerdefinierte Objekte kann der Zugriff über die Einstellung „Verwenden von Zugriff mithilfe von Hierarchien“Grant Access Using Hierarchies innerhalb einer Rollenhierarchie verhindert oder gewährt werden.

Zurück nach oben

VI. RollenhierarchieRole Hierarchy

Die RollenhierarchieRole Hierarchy stellt den Datenzugriff, den ein einzelner oder eine Gruppe von Benutzern benötigt, in Ebenen dar. Sie stellt z.B. sicher, dass Manager unabhängig von den organisationsweiten FreigabeeinstellungenOrganization Wide Defaults immer auf die gleichen Daten wie ihre Mitarbeiter zugreifen können.

Zusätzliche Info

  • Jede Rolle in der Hierarchie sollte eine eigene Ebene des Datenzugriffs repräsentieren.
  • Vom Administrator können bis zu 500 Rollen angelegt werden. Falls doch einmal mehr benötigt werden, kann Salesforce die Zahl auch noch erhöhen.

Als „Best Practice“ sollten in einer RollenhierarchieRole Hierarchy maximal 10 Verzweigungen genutzt werden.

Wenn sich die Rolle eines Benutzers ändert, werden alle relevanten FreigaberegelnSharing Rules ausgewertet, um den Zugriff bei Bedarf zu korrigieren. Zwei Benutzer auf derselben Ebene haben allerdings nicht unbedingt Zugriff auf dieselben Daten (beispielsweise die des jeweils anderen).

Die Modellierung der RollenhierarchieRole Hierarchy beginnt mit dem Verständnis der Organisationsstruktur. Diese wird üblicherweise aus der Sicht eines Managers aufgebaut, von oben nach unten.
Der Geschäftsführer steuert z.B. das gesamte Unternehmen. In der Regel verfügt er deshalb über direkte Berichte, die dann nach Geschäftsbereichen (Sales, Support, etc.) oder geografischen Regionen unterteilt werden können und so weiter. Auch wenn dies einem HR-Organigramm sehr ähnlich sieht, sollte sich bei der Modellierung des Datenzugriffs auf die Zugänglichkeit der Daten konzentrieren und die Hierarchie des Personals eher zweitrangig betrachtet werden.

Überschneidungen sind immer der schwierigste Teil der Hierarchie. Wenn sie auf einer Ebene sind, werden entweder FreigaberegelnSharing Rules, Teams oder die RegionsverwaltungTerritory Management benötigt, um die erforderlichen Rechte zu gewähren. Wenn sie in der Hierarchie untereinander stehen, kann es außerdem zu Auswirkungen bei AuswertungenReports kommen.

Es ist daher sehr wichtig, sich genügend Zeit für den Aufbau einer RollenhierarchieRole Hierarchy zu nehmen, da sie die Grundlage für das gesamte Freigabe-ModellSharing-Model bildet.

Anwendungsfälle

  • Management-Zugriff – die Fähigkeit für Manager, alles sehen und bearbeiten zu können, was auch ihre Mitarbeiter sehen und bearbeiten können.
  • Management-Reporting – die Möglichkeit das Reporting hierarchisch abzubilden, so dass jeder, der höher in der Hierarchie steht, mehr Daten sieht als die darunter liegenden.
  • Trennen von Geschäftseinheiten – um die Sichtbarkeit für einzelne Gebiete (auf Abteilungs- oder geografischer Ebene) losgelöst voneinander, bis zur Führungsebene zu betrachten.
  • Trennung innerhalb einer Rolle – da nicht alle Mitarbeiter einer Abteilung die gleichen Aufgaben haben und die Daten des jeweils anderen sehen sollen bzw. müssen, können die einzelnen Rollen in kleinere Ebenen mit einschränkenden Berechtigungen unterteilt werden.

Zurück nach oben

VII. Öffentliche GruppenPublic Groups

Öffentliche Gruppen (keine Chatter Gruppen) sind eine Zusammensetzung aus verschiedenen Benutzern, Rollen, Gebiete und so weiter. Sie bestehen aus:

  • Benutzern
  • Kundenportal Benutzer (Classic)
  • Partner Benutzer
  • Rollen und internen sowie Portal untergeordneten Rollen
  • Gebieten und untergeordneten Mitgliedern
  • Anderen öffentlichen Gruppen

Öffentliche GruppenPublic Groups können verschachtelt werden (Gruppe A in Gruppe B), aber auch nicht mehr als 5 Ebenen. Die Verschachtelung hat dann aber Auswirkung auf die Berechnungen der Gruppenzugehörigkeit. Es wird daher empfohlen, nicht mehr als 100.000 öffentliche Gruppen anzulegen.

Anwendungsfälle

  • Wenn eine Gruppe aus willkürlichen Benutzern Zugriff auf bestimmte Objekte benötigt. Das funktioniert nur in Verbindung mit einer FreigaberegelSharing Rule.
  • Zum Abbilden einer kleinen Hierarchie, wenn Gruppen miteinander verschachtelt werden. Dabei wird die RollenhierarchieRole Hierarchy nicht berücksichtigt.
  • Wenn Daten in einem privaten Freigabe-Modellprivate sharing model nur mit Benutzern innerhalb der Gruppe geteilt werden sollen. In diesem Fall greift die RollenhierarchieRole Hierarchy nicht. Diese Datensätze sind somit nur für die sich innerhalb der Gruppe befindlichen Benutzer zugänglich.

Zurück nach oben

VIII. FreigaberegelnSharing Rules

1. Datensatzinhaber-FreigaberegelnOwnership-based Sharing Rules

Freigaberegeln die auf Datensatzinhabern basieren können die organisationsweiten FreigabeeinstellungenOrganization Wide Defaults und die RollenhierarchieRole Hierarchy überschreiben. Sie können Benutzern zusätzlichen Zugriff auf Datensätze geben, den sie sonst nicht besitzen würden. Diese FreigaberegelnSharing Rules basieren ausschließlich auf dem Eigentümer des Datensatzes.

Zusätzliche Info

  • FreigaberegelnSharing Rules für Kontakte, die auf Datensatzinhabern basieren, funktionieren nicht mit privaten Kontakten.

Es wird empfohlen, nicht mehr als 1.000 FreigaberegelnSharing Rules pro Objekt anzulegen.

Anwendungsfälle

  • Ein Benutzer aus dem Bereich Service benötigt Zugriff auf Datensätze von einem Benutzer aus dem Vertrieb, aber sie befinden sich auf unterschiedlichen Ebenen der RollenhierarchieRole Hierarchy.
  • Benutzer in der gleichen Rolle wie der Besitzer benötigen Zugriff auf dessen Datensätze.
  • Öffentliche GruppenPublic Groups, Rollen oder RegionenTerritory benötigen Zugriff auf Datensätze, die einem bestimmten Benutzer gehören.

Zurück nach oben

2. Kriterienbasierte-FreigaberegelnCriteria-based Sharing-Rules

FreigaberegelnSharing Rules, die auf Kriterien basieren, können durch Werte in den Datensätzen beeinflusst werden. Die FreigaberegelSharing Rule löst aus, sobald die Kriterien erfüllt sind. Der Datensatzinhaber hat hierbei keinen Einfluss.

Zusätzliche Info

  • Es können maximal 50 Freigaberegeln, die auf Kriterien basieren, pro Objekt angelegt werden. Dieser Wert kann durch Salesforce allerdings noch erweitert werden.

Anwendungsfälle

  • Bestimmte Benutzer oder Gruppen sollen Zugriff auf bestimmte Datensätze bekommen, sobald festgelegte Kriterien erfüllt sind.

Zurück nach oben

3. Manuelle Freigabe für BenutzerdatensätzeManual Sharing

Manuelle Freigaben werden benutzt, wenn keine andere Möglichkeit einem Benutzer Zugriff auf einen bestimmten Datensatz gibt. In diesem Fall kann der Datensatzinhaber selbst entscheiden, ob er sichtbar und/oder bearbeitbar für einen anderen Benutzer oder eine öffentliche Gruppepublic Group ist.
Manuelle Freigaben sind keine automatischen Regeln und müssen daher immer manuell erstellt werden.

Zusätzliche Info

  • Der Zugriff auf manuell freigegebene Datensätze verschwindet, sobald sich der Datensatzinhaber ändert.
  • Zudem werden alle entsprechenden Regeln gelöscht, wenn die unternehmensweiten Standardeinstellungen für das Objekt den Zugriff auf diesen Datensatz generell erlauben.

Anwendungsfälle

  • Wenn ein Benutzer einen bestimmten Datensatz, für einen anderen Benutzer, Gruppe oder Rolle freigeben möchte. Dabei unterscheidet man zwischen Schreibgeschütztem- und Lese/Schreib-Zugriff.

Zurück nach oben

IX. Teams

Ein Team ist eine Gruppe von Benutzern, die gemeinsam an einem Account, einer Opportunity oder einem Case arbeitet. Mitarbeiter können für jeden Datensatz, den sie besitzen, ein Team bilden. Der Datensatzinhaber fügt Teammitglieder hinzu und gibt die Zugriffsstufe an, die jedes Teammitglied für den Datensatz hat. Einige Teammitglieder können nur Lesezugriff haben, während andere Lese-/Schreibzugriff bekommen.

Nur Eigentümer, hierarchisch höhere Personen und Administratoren können Teammitglieder hinzufügen und mehr Zugriff für das Mitglied gewähren. Ein Teammitglied mit Schreib-/ Lesezugriff kann ein weiteres Mitglied hinzufügen, das bereits Zugriff auf den Datensatz hat, mit dem das Team arbeitet. Ein Teammitglied kann keinen zusätzlichen Zugang gewähren.

Beim Anlegen eines Teammitglieds in Salesforce werden zwei Datensätze erstellt: ein Team-Datensatz und ein zugehöriger Freigabe-Datensatz. Wenn sie Teammitglieder programmgesteuert anlegen, müssen sie sowohl den Team-Datensatz als auch den zugehörigen Freigabe-Datensatz verwalten. Es gibt nur ein Team pro Datensatz (Account, Opportunity oder Case). Wenn mehrere Teams benötigt werden, sollten Sie je nach Ihren spezifischen Bedürfnissen RegionsverwaltungTerritory Management oder programmgesteuert FreigabenProgrammatic Sharing in Betracht ziehen.

Zusätzliche Info

  • Sie können keine benutzerdefinierten Felder, Validierungsregeln oder Trigger für Teams erstellen.

Anwendungsfälle

  • Um dem Benutzer die Möglichkeit zu geben, einer Gruppe von Benutzern (dem Team) Zugriff zu gewähren (nur lesend oder lesend/schreibend).
  • Werden Teams extern, z.B. über ein externes Provisions- oder Gebietsmanagementsystem geführt, kann die Integration zur Führung des Account-Teams genutzt werden. Es gibt Fälle, in denen das Gebietsmanagement in einem externen System auf eine Teamlösung in Salesforce abgestimmt werden kann.
  • Mehrere Besitzer eines Accounts können vom Account-Team verwaltet werden.
  • Eine einzelne Gruppe von Benutzern (Team) benötigt entweder nur Lese- oder Schreib-/ Lesezugriff auf einen Opportunity-Datensatz (Opportunity-Team).

Zurück nach oben

X. RegionshierarchieTerritory Hierarchy

Die Regionshierarchie ist eine zusätzliche, eindimensionale Hierarchie, die nach Geschäftsbereichen oder beliebigen Segmentierungen strukturiert werden kann. Wenn die RegionsverwaltungTerritory Management aktiviert ist, müssen Sie sowohl die RollenhierarchieRole Hierarchy als auch die RegionshierarchieTerritory Hierarchy verwalten.

Zusätzliche Info

  • Regionen existieren nur für Accounts, Opportunities und Master/Detail-Beziehungen von Accounts und Opportunities.
  • Organisationen können bis zu 500 Regionen anlegen; diese Zahl kann jedoch durch Salesforce erhöht werden.
  • Wenn die Zuordnungsregelnassignment rules für eine Regionterritory geändert werden, werden alle Freigaberegeln für AccountregionenAccount Territory sharing rules, die diese Region nutzen, neu berechnet.
  • Wenn sich die Zugehörigkeit zu einer Region ändert, werden die Datensatzinhaber-FreigaberegelnOwnership-based Sharing Rules, die diese Region hinterlegt haben, ebenfalls neu berechnet.

Als Best Practice empfiehlt es sich, die RegionshierarchieTerritory Hierarchy auf maximal 10 Ebenen in der Hierarchie zu beschränken

Anwendungsfälle

  • Mehrere Personengruppen (mehrere Teams) benötigen entweder Lesezugriff oder Lese-/Schreibzugriff auf Accounts.
  • Es wird eine zusätzliche hierarchische Struktur (abweichend von der RollenhierarchieRole Hierarchy) benötigt.
  • Ein einzelner Benutzer muss mehrere Ebenen in der Hierarchie verwalten.
  • Globale Benutzer (GAM – Global Account Manager) müssen alles von einem globalen Account nach unten sehen.

Zurück nach oben

1. Freigaberegeln für AccountregionenAccount Territory Sharing Rules

Die Freigaberegeln für Accountregionen sind nur verfügbar, wenn die RegionsverwaltungTerritory Management für die Organisation aktiviert ist. Diese Freigaberegeln ermöglichen den Zugriff auf Accountdatensätze, die mit der in der Regel definierten Region hinterlegt wurden.

Anwendungsfälle

  • Bereitstellung des Zugriffs auf Accounts innerhalb einer Region für eine Gruppe von Benutzern (nicht auf der Basis des Inhabers). Gilt nur für Accounts und wenn die RegionsverwaltungTerritory Management aktiviert ist.

Zurück nach oben

XI. Programmgesteuerte-FreigabenProgrammatic Sharing

Programmgesteuerte-Freigaben (offiziell Apex-organisierte Freigaben) erlauben es, Programm-Code (Apex oder ähnliches) dafür zu nutzen, anspruchsvolle, dynamische FreigaberegelnSharing Rules zu entwickeln – insbesondere wenn die Anforderungen zum Datenzugriff nicht mit anderen Mitteln erfüllt werden können.
Wenn ein Freigabesatz programmatisch erstellt und die Standardeinstellungen (manuelle Freigabe) verwendet wird, dann kann dieser Freigabesatz über die Teilen-Schaltfläche in der Anwendung verwaltet werden. Der Freigabesatz unterliegt allen Regeln, die mit der manuellen Freigabezeile verbunden sind, wie z.B. das Löschen bei der Übertragung des Eigentümers.

Anwendungsfälle

  • Keine andere Freigabe-Methode erfüllt die Anforderungen des Datenzugriffs.
  • Es gibt ein externes, führendes System für die Zuweisung von Benutzerrechten, das den Zugriff steuert und in Salesforce integriert werden soll.
  • Geringe Performance bei der Nutzung nativer Freigabe-Komponenten (tritt häufig bei der Verarbeitung sehr großer Datenmengen auf)
  • Team-Funktionalitäten auf den benutzerdefinierten Objekten.

Zurück nach oben

XII. Implizite-FreigabenImplicit Sharing

Implizite-Freigaben erfolgen automatisch. Sie können weder aus- noch eingeschaltet werden – es ist nativ in der Anwendung. Das bedeutet, dass dies keine konfigurierbare Einstellung ist. Allerdings ist es für jeden Architekten sehr wichtig, sie zu verstehen. Die Implizite-Freigabe durch Eltern ermöglicht den Zugriff auf Elterndatensätze (nur Account), wenn ein Benutzer Zugriff auf Kindselemente (Opportunity, Case, Kontakt) für diesen Account hat. Salesforce verfügt über eine Datenzugriffsrichtlinie, die besagt: wenn ein Benutzer einen Kontakt (eine Opportunity, einen Case oder einen Auftrag) sehen kann, sieht er implizit auch den zugehörigen Account.
Untergeordnete-Implizite-FreigabeChild implicit sharing ist die Bereitstellung des Zugriffs auf die untergeordneten Datensätze eines Accounts für den Inhaber. Dieser Zugriff wird in der Rolle des Inhabers in der RollenhierarchieRole Hierarchy definiert. Die Untergeordnete-Implizite-Freigabe gilt nur für Kontakt-, Opportunity- und Caseobjekte (Kinder des Accounts). Die Zugriffsebenen, die zur Verfügung gestellt werden können, sind Lesenread, Bearbeitenedit und Kein Zugriffno access für jedes der untergeordneten Objekte beim Anlegen der Rolle. Durch die Einstellung auf Lesen kann der Accountinhaber implizit die zugehörigen Objektdatensätze (Kontakt, Opportunity oder Case) einsehen und so weiter.

Zusätzliche Info

  • Die Implizite-Freigabe gilt nicht für benutzerdefinierte Objekte.

Zurück nach oben