Eigentümerschaft und Lebenszyklus

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 8 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Beziehungen haben Folgen · Weiter: Daten konsistent halten

Die Frage, die dieses Modul beantwortet: Wem gehört der Datensatz, und was passiert mit ihm im Lauf seines Lebens?

Wenn ich mir ein Datenmodell ansehe, will ich nicht nur wissen, was die Objekte sind und wie sie zusammenhängen. Ich will wissen, was mit den Datensätzen im Lauf der Zeit passiert. Wer erstellt sie? Wem gehören sie? Wer kann sie neu zuweisen? Was passiert, wenn sich die Geschäftsbeziehung ändert, wenn sie nicht mehr aktiv sind? Sollten sie je gelöscht werden, und wie lange bewahren wir sie auf? Nichts davon erscheint in einem ER-Diagramm, dem Entity-Relationship-Diagramm: den Kästen und Linien des Datenmodells aus Kapitel 2. Alles davon ist Datenarchitektur. Und auf Salesforce ist die Eigentümerschaft die Stelle, an der Datenmodell und Sicherheitsmodell aufeinandertreffen.

Eigentümerschaft ist mehr als ein Name in einem Feld

In der Administration sieht man auf einem Datensatz Eigentümer und liest es als Beschriftung: Bart gehört dieser Account, Lisa gehört jener Kundenvorgang. Das kann es bedeuten. Aber auf Salesforce ist die Eigentümerschaft auch ein Mechanismus der Plattform. Bei Objekten mit Eigentümer bestimmt der Eigentümer, wer den Datensatz sehen kann, über die Rollenhierarchie, Freigaberegeln, Warteschlangen und Neuzuweisung. Wenn ich also frage «Wem gehört dieser Datensatz?», frage ich nicht, wessen Name auf der Seite steht. Ich frage, welches Sicherheits- und Lebenszyklusverhalten wir daran knüpfen. Der Eigentümer kann ein Benutzer sein oder bei manchen Objekten, darunter benutzerdefinierte Objekte, Kundenvorgänge und Leads, eine Warteschlange, und so oder so bekommt der Eigentümer vollen Zugriff auf den Datensatz (Understanding Sharing (opens in a new tab), auf Englisch).

Deshalb trenne ich geschäftliche Verantwortung von Datensatzeigentümerschaft. Manchmal ist es dieselbe Person. Manchmal nicht. Wenn das Geschäft sagt, die Disposition ist für eine Lieferung verantwortlich, macht das die Person in der Disposition nicht automatisch zum Datensatzeigentümer. Die Verantwortung kann in einem eigenen Feld stehen, während die Eigentümerschaft so gesetzt wird, dass sie Sicherheit und Volumen trägt. Lassen Sie die beiden nicht verwechseln, nur weil beide das Wort «Eigentümer» verwenden.

Die Freigabetabelle: wo Eigentümerschaft zu Zugriff wird

Manche wissen nicht einmal, was die Freigabetabelle ist. Alle, die Datenarchitektur machen, sollten es wissen.

Der grösste Teil der Freigabe eines Datensatzes wird in einem zugehörigen Freigabeobjekt (Share Object) gehalten, der Salesforce-Version einer Zugriffssteuerungsliste (Understanding Sharing (opens in a new tab), auf Englisch). Account hat AccountShare, Kontakt hat ContactShare, und ein benutzerdefiniertes Objekt bekommt ein eigenes: Truck__c hat Truck__Share (Sharing a Record Using Apex (opens in a new tab), auf Englisch). Jede Zeile darin sagt vier Dinge:

• Welcher Datensatz: die ID des übergeordneten Datensatzes.
• Wer: ein Benutzer oder eine Gruppe (eine öffentliche Gruppe, die Gruppe einer Rolle, ein Gebiet).
• Wie viel: Read (Lesen), Edit (Bearbeiten) oder All (Vollzugriff).
• Warum: die Zeilenursache (Row Cause). Owner für den Eigentümer, Rule für eine Freigaberegel, Manual für eine manuelle Freigabe, Team, die impliziten Ursachen, die Salesforce zwischen einem Account und seinen untergeordneten Datensätzen hinzufügt, und Gründe, die ein Entwicklungsteam für die Apex-Freigabe definiert.

Im Kurs öffne ich Workbench und frage die Freigabetabelle ab, während ich einen Datensatz freigebe, und Sie sehen die Zeilen erscheinen und verschwinden. Wenn jemand fragt «Warum kann diese Person das sehen?», steht die Antwort oft in einer Zeile, mit ihrem Grund.

Aber nicht alles steht darin. Die organisationsweite Standardeinstellung ist keine Zeile. Auch die Rollenhierarchie wird dort nicht gespeichert: Der Zugriff für die Personen über dem Eigentümer wird erst ermittelt, wenn er gebraucht wird. Und View All, Modify All, View All Data und Modify All Data umgehen die Freigabetabelle vollständig (Sharing a Record Using Apex (opens in a new tab), auf Englisch). Wie ich es im Kurs sage: Haken Sie View All an, und Sie haben die Freigabetabelle umgangen.

Salesforce gibt manche Datensätze auch selbst für Sie frei, wegen der Art, wie sie zusammenhängen. Das ist die implizite Freigabe, und sie wirkt zwischen einem Account und seinen untergeordneten Datensätzen. Wenn Sie einen Kontakt, einen Kundenvorgang oder eine Opportunity sehen können, können Sie auch den Account lesen, zu dem er gehört. Und der Account-Eigentümer bekommt Zugriff auf die Kontakte, Kundenvorgänge und Opportunities des Accounts, auf einer Stufe, die die Rolle des Eigentümers festlegt (Implicit Sharing (opens in a new tab), auf Englisch). In neueren Releases ermittelt Salesforce einen Teil dieses Zugriffs auf untergeordnete Datensätze erst, wenn er gebraucht wird, statt ihn als Zeilen zu speichern; wundern Sie sich also nicht, wenn eine Abfrage der Freigabetabelle ihn nicht zeigt. Ich gebe Ihnen hier nur einen Hinweis; die Einzelheiten stehen in Relationships and Built-In Sharing (auf Englisch).

Noch eine Ausnahme, für den Fall, dass Sie viele externe Benutzer haben. High-Volume-Community-Benutzer, die Customer-Community-Lizenzen für Tausende bis Millionen Kund:innen, haben keine Rolle, können nicht in öffentlichen Gruppen sein und können keine Datensätze über Freigaberegeln oder manuelle Freigaben bekommen (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab), auf Englisch). Für sie ist die Freigabetabelle nicht die Antwort: Sie gelangen über Freigabesätze an Datensätze, die den Account oder Kontakt eines Datensatzes mit dem eigenen des Benutzers abgleichen. Das ist einer der Gründe, warum diese Lizenzen skalieren. Der Kurs Sharing and Visibility behandelt das in Sharing with External Users (auf Englisch).

Und denken Sie an Modul 7: Ein Detailobjekt hat überhaupt kein Freigabeobjekt. Sein Zugriff kommt aus dem Freigabeobjekt des Masters und der Sharing Setting (Freigabeeinstellung) auf dem Master-Detail-Feld.

Warum kümmert das die Datenarchitektur? Weil die Eigentümerschaft in diese Tabelle geschrieben wird. Jeder Eigentümerwechsel, jede neue Freigaberegel, jeder Benutzer, der Rolle oder Gruppe wechselt, bedeutet, dass Salesforce Zeilen hinzufügt und entfernt. Bei ein paar Tausend Datensätzen merkt das niemand. Bei zehn Millionen, von denen die meisten einem Benutzer gehören, ist das die Neuberechnung, der wir gleich begegnen.

Prüfungswissen. Das Freigabeobjekt eines benutzerdefinierten Objekts heisst Object__Share, etwa Truck__Share. Ein Detailobjekt hat kein Freigabeobjekt: Sein Zugriff kommt vom Master. Und wenn sich der Eigentümer eines Datensatzes ändert, werden seine manuellen Freigaben entfernt, während Apex-Freigaben mit einem eigenen Grund des Entwicklungsteams bleiben.

Hier übergibt das Datenmodell an das Sicherheitsmodell, und den Rest unterrichte ich im Kurs Sharing and Visibility Architect (auf Englisch): Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, Relationships and Built-In Sharing für die impliziten Freigaben und Programmatic Sharing and Secure Code für Apex-Freigabegründe. In diesem Kurs führt Kapitel 12 alles für Menschen, Anwendungen und Agenten zusammen.

Manchmal wird die Eigentümerschaft geerbt

Im letzten Modul haben wir gesehen, dass ein Master-Detail-Kind keinen eigenen Eigentümer hat; es folgt seinem übergeordneten Datensatz. Das ist oft genau richtig. Braucht das Geschäft für jede Position einer Lieferung einen anderen Eigentümer? Nein. Die Lieferung besitzt den Lebenszyklus, und die Position gehört zu ihr. Deshalb geschehen Beziehungsentwurf und Eigentümerschaftsentwurf gemeinsam: Als Sie Master-Detail gewählt haben, hatten Sie einen Teil der Eigentümerschaftsentscheidung schon getroffen.

Wem gehören Datensätze, die Systeme erstellen?

Jetzt wird es interessant. Eine Person erstellt einen Account, und vielleicht wird der Datensatz ihr zugeordnet. Aber ein ERP schickt über Nacht 100’000 Transaktionen. Wem gehören die? Dem Integrationsbenutzer? Einer Warteschlange? Einem regionalen Eigentümer, der aus den Daten ermittelt wird? Einem Systemkonto, an das seit fünf Jahren niemand gedacht hat? Und jetzt erstellen auch Agenten Datensätze.

Meine Position: Es hängt davon ab, ob die Eigentümerschaft für die Freigabe zählt. Der Integrationsbenutzer oder der Agentenbenutzer ist ein gültiger Benutzer, und er kann die Datensätze besitzen. Wenn die Eigentümerschaft in diesem Objekt den Zugriff steuert (über die Rollenhierarchie oder Freigaberegeln), weisen Sie die Datensätze dem richtigen Eigentümer zu: einem echten Benutzer, einer Warteschlange oder einem eigens dafür bestimmten Eigentümerbenutzer. Wenn nicht, ist es vielleicht besser, den Systembenutzer als Eigentümer zu behalten, denn dann führt der Prüfpfad direkt zu dem zurück, was den Datensatz erstellt hat.

So oder so: Entscheiden Sie es bewusst. Ein Integrationskonto, dem alles gehört, ist stillschweigend Teil Ihrer Sicherheitsarchitektur geworden, und jemand muss wissen, was passiert, wenn es je deaktiviert wird.

Eigentümerschaft kann zum Volumenproblem werden

Auch die Verteilung zählt. Zehn Millionen Datensätze auf Tausende Eigentümer verteilt sind eine Form. Zehn Millionen Datensätze, die einem Benutzer gehören, sind eine ganz andere. Salesforce nennt es Eigentümerschafts-Datenschieflage (Ownership Data Skew), wenn ein einzelner Benutzer mehr als 10’000 Datensätze eines Objekts besitzt (Ownership Data Skew (opens in a new tab), auf Englisch). Meist passiert das, wenn jemand alles bei einem Benutzer oder einer Warteschlange parkt: alle nicht zugewiesenen Leads bei einem Platzhalterbenutzer, jeden Integrationsdatensatz beim Integrationsbenutzer. Das ist harmlos, bis dieser Benutzer in der Rollenhierarchie verschoben wird oder in eine Gruppe ein- oder austritt, von der eine Freigaberegel abhängt. Dann muss Salesforce eine riesige Zahl von Freigabeeinträgen anpassen, und Sie bekommen lang laufende Neuberechnungen.

Die Empfehlung ist praktisch. Verteilen Sie die Eigentümerschaft auf mehr Benutzer, wo Sie können. Wenn ein Benutzer viel besitzen muss, halten Sie ihn aus der Rollenhierarchie heraus; braucht er eine Rolle, geben Sie ihm eine eigene Rolle ganz oben und verschieben Sie ihn nicht, und halten Sie ihn aus öffentlichen Gruppen heraus, die Freigaberegeln verwenden (Ownership Data Skew (opens in a new tab), auf Englisch). Dasselbe Denken gilt für den übergeordneten Datensatz mit zu vielen untergeordneten aus dem letzten Modul, die Eltern-Kind-Schieflage.

Die Verteilung ist also Teil des physischen Modells. Fragen Sie nicht nur, wie viele Datensätze; fragen Sie, wie sie verteilt sind. Das ist eine weitere Version der Anzahl der Nullen: nicht nur wie viele Nullen, sondern wo sich die Nullen konzentrieren. Teil 2 geht tief auf die Schieflage ein; hier möchte ich, dass Sie sie kommen sehen. Der Kurs Sharing and Visibility greift sie in Sharing at Scale (auf Englisch) wieder auf.

Der «Standardeigentümer» wird zur Architektur

Hier ein Muster, das ich ständig sehe. Niemand weiss, wem etwas gehören soll, also sagt jemand: «Weisen wir einfach alles dem Integrationsbenutzer zu», oder «Legen wir einen generischen Benutzer namens System an.» Vielleicht ist das richtig. Aber tun Sie es nicht aus Versehen. Ein vorübergehender Standard wird gern dauerhaft: Zwei Jahre später gehört jeder Datensatz integration@company.com, niemand weiss mehr warum, und es zu ändern ist ein Projekt. Das ist der Umkehrbarkeitstest aus Kapitel 1: Bevor Sie einem Eigentümer eine Million Datensätze geben, fragen Sie, was es später kostet, das zu ändern.

Neuzuweisung ist ein Lebenszyklusereignis

Eigentümer wechseln. Leute im Vertrieb gehen, Gebiete verschieben sich, Teams werden umorganisiert, Regionen neu verteilt. Was hängt vom Eigentümer ab: Freigabe, Automatisierung, Berichte, Warteschlangen, Eskalationen, Integrationen? Wenn ein Eigentümerwechsel ändert, wer den Datensatz sehen kann, ist die Neuzuweisung kein Aufräumen in der Administration. Sie ist ein Sicherheitsereignis, und bei einer Million Datensätzen auch ein betriebliches. Beobachten Sie die Freigabetabelle, wenn es passiert: Manuelle Freigaben werden entfernt, wenn sich der Eigentümer ändert, während Apex-Freigaben mit einem eigenen Grund des Entwicklungsteams den Wechsel überstehen (Understanding Sharing (opens in a new tab), auf Englisch). Im Kurs gebe ich einen Datensatz für jemanden frei, ändere den Eigentümer, und die Person verliert den Zugriff. Der Raum ist jedes Mal überrascht.

Und denken Sie daran, dass Eigentümerschaft nicht dasselbe ist wie Zugriff. Der Eigentümer ist nicht die einzige Person, die einen Datensatz sehen muss, und Salesforce hat viele Wege, Zugriff zu gewähren: die Rollenhierarchie, Freigaberegeln, Teams, Gebiete, manuelle und programmatische Freigabe. Der Kurs Sharing and Visibility geht darauf in die Tiefe, beginnend mit Steve’s 22 Ways to Share a Record (auf Englisch). Der Punkt der Architektur ist einfacher: Lösen Sie nicht jedes Zugriffsproblem über die Eigentümerschaft. Wenn Sie Eigentümer herumschieben, nur damit jemand einen Datensatz sehen kann, lösen Sie wahrscheinlich das falsche Problem.

Die Erstellung ist erst der Anfang

Viel Datenmodellierung hört bei der Erstellung auf: die Felder, das Objekt, die Beziehung, fertig. Aber der Datensatz lebt vielleicht zehn Jahre. Er wird aktualisiert, wechselt den Eigentümer, ändert Status und Beziehungen, wird inaktiv, wird zur Historie, muss vielleicht archiviert und eines Tages vielleicht gelöscht werden. Architektur ist nicht nur, wie der Datensatz geboren wird. Sie ist alles, was von der Geburt bis zum Tod passiert.

Click to enlarge

Löschen Sie nicht, nur weil etwas alt ist

Ein Handelspartner schickt keine Aufträge mehr. Den Account löschen? Nicht automatisch: Seine Lieferungen, Reklamationen und Abrechnungshistorie zählen weiterhin. Ein Lastwagen wird ausgemustert. Ihn löschen, samt Lieferhistorie und Schadensmeldungen? Das Ding ist vielleicht nicht mehr aktiv, aber seine Daten sind es noch. Ich trenne also inaktiv von weg. Ein ausgemusterter Lastwagen kann im Modell bleiben; frühere Mitarbeitende können weiterhin in der Prüfhistorie erscheinen. Die Architektur muss die Tatsachen bewahren, die zählen, nachdem die betriebliche Beziehung endet.

Aufbewahrung ist eine geschäftliche Anforderung

Die andere Seite: Alles für immer zu behalten ist auch keine Architektur. Der Speicher wächst, Berichte werden langsamer, die Suche wird lauter, und das Datenschutzrecht verlangt vielleicht, dass manche Daten gehen müssen. Ich möchte also eine ausdrückliche Antwort auf Wie lange bewahren wir das auf? «Salesforce bewahrt es auf» ist keine Aufbewahrungsrichtlinie.

Und meistens ist das eine Frage der Bewegungsdaten. Referenzdaten, die Produkte, die Servicearten, die Verteilzentren, werden nicht riesig, und andere Datensätze zeigen auf sie, also bleiben sie meist. Kundendaten liegen dazwischen: Es kann der Tag kommen, an dem Sie einen Kunden auslaufen lassen, besonders wenn Sie personenbezogene Daten halten und der Grund für ihre Aufbewahrung endet. Aber das Volumen steckt in den Transaktionen: den Lieferungen, den Aufträgen, den Kundenvorgängen, den Terminen, jeden Tag neu erstellt, für immer. Das wächst auf Hunderte Millionen Zeilen, und dort muss die Aufbewahrung ausdrücklich sein: vielleicht zwei Jahre operative Daten in der Org, sieben Jahre Finanzunterlagen irgendwo, neunzig Tage für manche Fotos. Das sind Geschäftsregeln, und wenn niemand gefragt hat, sollte die Architektur es tun.

Ich sage es seit Jahren im Kurs: Wenn Sie heute nicht archivieren, werden Sie es dann je tun? «Darum kümmern wir uns später» wird bei dreihundert Millionen Datensätzen gern zum Notfallprojekt. Teil 2 hat ein ganzes Modul zum Archivieren und Bereinigen, aufgebaut auf derselben Frage.

Steve Trucking: Wem gehört eine Lieferung?

Eine Lieferung wird aus der Ladeliste des Handelspartners erstellt, von einer Integration, etwa 3’300-mal am Tag. Wem gehört sie? Nicht dem Handelspartner; das ist eine Geschäftsbeziehung. Nicht dem Empfänger. Die Crew führt sie aus, aber soll der Datensatz jedes Mal den Eigentümer wechseln, wenn Crews die Lastwagen tauschen? Der Disposition? Dem Verteilzentrum? Einer Warteschlange? Dem Integrationsbenutzer, der sie erstellt hat?

Wenden Sie jetzt dieses Modul an, beginnend mit der Frage, die es entscheidet: Steuert die Eigentümerschaft den Zugriff von irgendjemandem auf Lieferungen? Bei Steve Trucking nicht. Die Disposition sieht die Lieferungen ihres Verteilzentrums, Crews sehen die auf ihren Touren, und jeder Handelspartner sieht seine eigenen im Partnerportal. Nichts davon hängt davon ab, wem der Datensatz gehört; es kommt vom Verteilzentrum, der Tour und dem Partner.

Meine Antwort also: Die Lieferungen gehören dem Integrationsbenutzer. Das ist ein gutes Beispiel für einen Systembenutzer, dem Datensätze mit Absicht gehören:

• Der Prüfpfad ist ehrlich. Der Eigentümer jeder Lieferung sagt, woher sie kam: von der Ladelisten-Integration.
• Der Zugriff kommt aus der Freigabe, nicht aus der Eigentümerschaft. Kriterienbasierte Freigaberegeln auf dem Verteilzentrum geben dem Team jedes Verteilzentrums seine Lieferungen; Partner erreichen ihre über das Portal.
• Die Schieflage ist wegkonstruiert. Bei 3’300 am Tag überschreitet der Integrationsbenutzer in drei Tagen 10’000 Lieferungen, es ist also vom ersten Tag an Eigentümerschafts-Schieflage, und das ist in Ordnung, wenn wir sie einplanen. Der Integrationsbenutzer hat keine Rolle, also muss nichts über ihm in einer Hierarchie neu berechnet werden, und er bleibt aus den öffentlichen Gruppen heraus, die unsere Freigaberegeln verwenden.
• Niemand weist Lieferungen neu zu. Crews tauschen Lastwagen, die Disposition wechselt die Schicht, und der Eigentümer bewegt sich nie, also gibt es keinen Neuzuweisungssturm und keine manuellen Freigaben, die verloren gehen.

Und schreiben Sie auf, was passiert, wenn dieser Benutzer je deaktiviert oder ersetzt wird, denn ihm gehören jetzt Millionen Datensätze. Das ist die Entscheidung, die das nächste Team finden muss.

Über die Prüfung hinaus: Was KI ändert. Agenten erstellen und ändern Datensätze in Maschinengeschwindigkeit. Wenn ein Agent 100’000 Datensätze unter seinem eigenen Benutzer erstellt, wird «Wir korrigieren den Eigentümer später» zu Schieflage, einer Neuberechnung der Freigabe und einem Aufräumprojekt. Entscheiden Sie die Eigentümerschaftsregel des Agenten, bevor er live geht, mit derselben Frage: Zählt die Eigentümerschaft hier für die Freigabe?

Was Architekt:innen hier entscheiden

• Ob die Eigentümerschaft geschäftliche Verantwortung, einen Sicherheitsmechanismus oder beides darstellt, und wo die Verantwortung steht, wenn nicht im Feld Eigentümer.
• Ob Datensätze einen eigenen Eigentümer brauchen oder ihn von einem übergeordneten erben sollten.
• Wem die Datensätze gehören, die Integrationen und Agenten erstellen, je nachdem, ob die Eigentümerschaft die Freigabe steuert.
• Wie die Eigentümerschaft verteilt ist und wie man Eigentümerschafts-Schieflage vermeidet, wenn ein Benutzer viel besitzen muss.
• Wann Datensätze inaktiv werden, wann sie archiviert werden, wie lange sie aufbewahrt werden und wann Löschen richtig ist.

Wenn Sie ein physisches Modell betrachten, fragen Sie nicht nur, wo die Daten gespeichert sind. Fragen Sie, wem sie heute gehören, wem sie morgen gehören könnten und was passiert, wenn wir sie nicht mehr brauchen. Als Nächstes: Selbst mit dem richtigen Objekt, den richtigen Feldern, Beziehungen und Eigentümern müssen die Daten vertrauenswürdig bleiben.

Weiterlesen

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (auf Englisch), geprüft am 2026-10-13: Eigentümer (ein Benutzer oder, bei benutzerdefinierten Objekten, Kundenvorgängen und Leads, eine Warteschlange) bekommen vollen Zugriff; der grösste Teil der Freigabe liegt in einem zugehörigen Freigabeobjekt; die Rollenhierarchie wird zur Laufzeit abgeleitet; manuelle Freigaben werden beim Eigentümerwechsel entfernt, verwaltete Apex-Freigaben bleiben; die Werte der Zeilenursache.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (auf Englisch), geprüft am 2026-10-13: AccountShare, MyCustomObject__Share; Detailobjekte haben kein Freigabeobjekt; was das Freigabeobjekt nicht erfasst (organisationsweite Standardeinstellungen, Rollenhierarchie, View All und Modify All).
• Salesforce-Hilfe, Implicit Sharing (opens in a new tab) (auf Englisch), geprüft am 2026-10-13: Zugriff zwischen einem Account und seinen Kontakten, Kundenvorgängen und Opportunities.
• Salesforce-Hilfe, About High-Volume Community or Site Users (opens in a new tab) und Sharing Rule Considerations (opens in a new tab) (auf Englisch), geprüft am 2026-10-13: keine Rollen, keine Freigaberegeln oder manuellen Freigaben; stattdessen Freigabesätze.
• Kurs Sharing and Visibility Architect (auf Englisch): Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, Relationships and Built-In Sharing, Programmatic Sharing and Secure Code, Sharing with External Users, Sharing at Scale.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) und Parent-Child Data Skew (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.