Wenn Volumen auf das Freigabemodell trifft

🌐 Auch in 19 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen Dieser Abschnitt hat sich im Englischen geändert und wurde noch nicht neu übersetzt. (35)

Modul 3 von 4 im Kapitel Für Skalierung entwerfen, Kapitel 7 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Hotspots: Eigentümerschafts-, Eltern- und Nachschlage-Schieflage · Weiter: Wenn Sie heute nicht archivieren …

Die Frage, die dieses Modul beantwortet: Wie bleibt ein Modell, das die Freigabe respektiert, bei hohem Volumen schnell?

Das letzte Modul hat die Hotspots gefunden. Jetzt kommt die Sicherheit dazu, und dort wird eine vernünftig aussehende Datenarchitektur teuer. Neun Millionen Arbeitsaufträge sind ein Volumenproblem. Neun Millionen Arbeitsaufträge, jeder sichtbar für genau die richtigen internen Benutzer und genau den richtigen Handelspartner, sind ein Problem der Freigabe bei hohem Volumen. Ein Datensatz wird nicht nur gespeichert; Salesforce muss auch beantworten: Wer darf ihn sehen? Im großen Maßstab ist diese Antwort Teil der Datenarchitektur.

Freigabe sind auch Daten

Wenn Architekt:innen Volumen zählen, zählen sie Geschäftsdatensätze. Aber Salesforce pflegt auch, was den Zugriff stützt: Eigentümer, Rollen, Gruppen, Freigaberegeln, explizite Freigaben, Mitgliedschaften. Im kleinen Maßstab kann man vergessen, dass diese Arbeit existiert. Im großen nicht. Deshalb sage ich nie: „Das Sicherheitsteam klärt die Freigabe später.“ Die Beziehung, die ich wähle, der Eigentümer, der Elterndatensatz, das Modell für externe Benutzer: Jedes davon beeinflusst die Freigabe. Datenarchitekt:in und Freigabearchitekt:in mögen verschiedene Personen sein, aber ihre Architekturen hängen zusammen.

The Share Table Has Its Own Number of Zeros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing (öffnet in einem neuen Tab); Sharing a Record Using Apex (öffnet in einem neuen Tab)). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros. ⟲

Salesforce describes three kinds of tables behind record access. The object record tables hold the records and who owns each one. The object sharing tables, the __Share objects, “store each access grant in separate rows called sharing rows, each of which grants a user or group access to a particular record.” And the group maintenance tables store who belongs to each group, and the access people inherit through roles and groups (Record-Level Access: Under the Hood (öffnet in einem neuen Tab), Winter ‘27, archived copy (öffnet in einem neuen Tab)). When we talked about recalculation, this is where the work happens: rows being added and removed in those tables. ⟲

So do the math for the share table the way we did it for the records. Say each of Steve Trucking’s 9 million work orders is shared by three sharing rules: to its Retail Partner’s users, to its distribution center’s managers, and to an operations region. Work Order’s share object is WorkOrderShare, “a sharing entry on a work order” (WorkOrderShare (öffnet in einem neuen Tab)). That’s three of those rows per work order, about 27 million sharing rows behind 9 million records, before the owner’s own rows. Share the same records with individual users instead of groups, and the rows multiply by the number of people. The share table can be far bigger than the object it protects. ⟲

Zum Vergrößern klicken

Step 1 of 3: the records. Nine million work orders. ⟲

Zum Vergrößern klicken

Step 2 of 3: the share table, three rules to groups. ⟲

Zum Vergrößern klicken

Step 3 of 3: the same access, shared person by person. Count the share table, not just the records. ⟲

That’s why the levers that keep sharing fast are mostly levers on the number of rows: ⟲

• Share with groups, not people. Salesforce’s own advice: grant access to the group instead of to the individuals, which “results in fewer sharing rows, thus reducing your organization’s record access data volume” (same source). ⟲
• A detail object has no share object at all. Its access comes from its master, so a master-detail child adds no sharing rows (chapter 3, and module 2’s Master-Detail at Volume for what that costs). ⟲
• High-volume community users don’t use sharing rows. They reach records through sharing sets instead, one of the reasons those licenses scale (chapter 3). ⟲
• Use a public default where the data isn’t confidential. A Public Read Only or Read/Write default needs no sharing rows to grant what everyone may already read (see Don’t Optimize Away Security, below). ⟲

Test knowledge. Know the share object (AccountShare, Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. ⟲

Beginnen Sie mit der Zugriffsanforderung

I don’t start with which sharing feature to use. I start with who needs access to what? For Steve Trucking, one requirement is clear: each Retail Partner sees its own deliveries, never another’s. Simple to say. At scale I immediately want to know how many partner users there are, how many deliveries, how a delivery relates to its partner, who owns the delivery, and what happens when a user changes roles, a partner user is added or removed, or a partner relationship changes, and how often any of that happens. The access requirement comes first; then a model that supports it at the zeros we expect. ⟲

Ownership Drives Access

That’s why “who should own the delivery?” can’t be answered in isolation. If one integration user owns every work order, ingestion is easy, but if the business expected ownership to drive access, we’ve given up that way of controlling access. And if ownership doesn’t drive access, forcing millions of records through complicated ownership assignments adds complexity for nothing. So my rule for machine-created records applies here too: does ownership matter for sharing? If it does, ownership should reflect the access model. If it doesn’t, we have more freedom. One decision, made by the data architect and the sharing architect together. ⟲

Die Rollenhierarchie ist kein Organigramm

Teams entwerfen die Rollenhierarchie als Spiegel des Organigramms. Dann strukturiert sich das Unternehmen um, jemand verschiebt eine Rolle, und Salesforce muss die Folgen für den Zugriff ausrechnen. Im kleinen Maßstab merkt das niemand. Bei Millionen Datensätzen ist eine Umstrukturierung eine große Datenoperation. Deshalb lautet die Empfehlung für Eigentümer mit hohem Volumen: keine Rolle, oder eine eigene, stabile Rolle ganz oben in der Hierarchie (Ownership Data Skew (öffnet in einem neuen Tab)). Das Prinzip lässt sich verallgemeinern: Im großen Maßstab ist Stabilität ein Entwurfsmerkmal. Je mehr Datensätze an einer Freigabestruktur hängen, desto vorsichtiger ändern Sie sie.

Bei Gruppen ist es dasselbe. Öffentliche Gruppen speisen Freigaberegeln; Benutzer gehören zu Gruppen; Gruppen enthalten Gruppen. Nützliche Werkzeuge, aber wenn riesige Mengen an Benutzern und Datensätzen von Gruppenmitgliedschaften abhängen, die sich ständig ändern, müssen Sie die Neuberechnung verstehen. Deshalb bleiben Eigentümer mit hohem Volumen aus öffentlichen Gruppen heraus, die als Quellen für Freigaberegeln dienen (dieselbe Quelle). Die Lektion lautet nicht „öffentliche Gruppen sind schlecht“. Sie lautet: Verbinden Sie Ihre größte Ballung von Datensätzen nicht ohne gründliches Nachdenken mit Ihren unbeständigsten Zugriffsstrukturen.

Die Neuberechnung der Freigabe ist echte Arbeit

Steve Trucking ändert sein Betriebsmodell: Hunderte Benutzer wechseln, Eigentümerschaft ändert sich, Rollen und Gruppen ändern sich, eine große Freigaberegel ändert sich. Das klingt nach Konfiguration. Aber die Plattform muss womöglich den Zugriff über eine große Menge an Datensätzen neu berechnen, also behandle ich es als Datenoperation. Wie viele Benutzer, Datensätze, Eigentümer- und Mitgliedschaftsänderungen? Wie viel Neuberechnung? Können wir es mit echtem Volumen testen? Wann soll es laufen, und was sehen die Benutzer in der Zwischenzeit? Eine große Neuausrichtung der Sicherheit verdient dieselbe Disziplin wie eine große Datenmigration.

And don’t recalculate everything after every change. Making one change, waiting for everything to recalculate, then the next, then the next, rebuilds access over and over while the design is still moving. Salesforce’s answer for large realignments is deferred sharing calculations: prepare all the role, group and sharing-rule changes, apply them in a negotiated maintenance window, and let the recalculation run once (Deferred Sharing Maintenance (öffnet in einem neuen Tab)). Change, change, change, recalculate once. Two more of Salesforce’s suggestions keep the work down: process role hierarchy changes from the bottom (leaf) nodes up, “to avoid duplicate processing,” and remove redundant paths of access, “such as sharing rules that provide access to people who already have it through the hierarchy” (Designing Record Access for Enterprise Scale (öffnet in einem neuen Tab), Winter ‘27). ⟲

Test knowledge. Know the tools for large access changes: deferred sharing calculations (prepare every change, apply them in an agreed maintenance window modeled in a full copy sandbox, recalculate once) and granular locking, on by default, which lets unrelated role and group operations run at the same time. ⟲

Zum Vergrößern klicken

At scale, access realignment is a data operation. ⟲

„Zurückgestellt“ heißt nicht „nebenbei“. Wenn eine Änderung groß genug ist, um die Freigabe zurückzustellen, will ich einen Plan: getestet mit realistischem Volumen, ein Wartungsfenster, dem das Geschäft zustimmt, Überprüfung, ein Ausweichplan, falls es nicht fertig wird, und ein Verständnis dafür, was die Benutzer währenddessen erleben. Die Empfehlung von Salesforce lautet, es zuerst in einer Full Sandbox zu modellieren (dieselbe Quelle), denn ein Sicherheitsmodell, das mit 5.000 Testdatensätzen wunderbar funktioniert, beweist nichts über 50 Millionen. Testen Sie die Anzahl der Nullen, für die Sie tatsächlich entwerfen.

Granulares Sperren hilft, ist aber kein Heilmittel

Role and group updates lock the group-membership tables while they run, which used to make unrelated sharing operations collide. Granular locking, now on by default, lets unrelated group operations run at the same time (Group Membership Locking (öffnet in einem neuen Tab)); retry logic, serial processing, and scheduling separate group maintenance jobs so they don’t overlap help with what’s left. The idea is worth remembering: don’t lock more of the access structure than the operation needs. But don’t conclude “locking is solved.” Granular locking reduces some contention. It doesn’t rescue a poor ownership model, a volatile hierarchy, or an access design that constantly forces massive recalculation. Platform features help; architecture still matters. ⟲

Steve Trucking: Partnertrennung im großen Maßstab

Bei Checkpoint 1 trägt jeder Arbeitsauftrag dauerhaft seinen Handelspartner, weil Partnertrennung eine Anforderung ist. Die Volumenzahlen machen das wichtiger, nicht weniger wichtig: Wenn Redrock 40 % des Geschäfts ausmacht, sind das rund 3,6 Millionen Redrock-Arbeitsaufträge über fünf Jahre. Die Beziehung stimmt; Redrock ist wirklich ein Partner. Also muss der Zugriffsentwurf der echten Geschäftsbeziehung folgen (Partnerbenutzer sehen die Arbeitsaufträge ihres Partners, Leitungen von Verteilzentren nur die ihres Zentrums), statt das Modell zu verzerren. Die Struktur mit einem Unter-Account pro Verteilzentrum aus dem letzten Modul hilft hier doppelt: Sie verteilt die Kinder, und sie gibt dem Zugriff auf Ebene des Verteilzentrums etwas Echtes, woran er hängen kann.

And keep authorization separate from identity. At the checkpoint we decided not to unify Recipients across partners, precisely because a shared identity is exactly the kind of link that can expose one partner’s data to another. Even where identity resolution is used inside one partner, it answers who might this person be? Sharing answers who may see this record? Blur them, and at this scale the mistake isn’t wrong once. It’s wrong millions of times. ⟲

Interner Zugriff ist wieder anders

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them. ⟲

Manchmal sollte Sicherheit das Modell verändern. Wenn zwei Arten von Information völlig unterschiedliche Eigentümer, Lebenszyklen, Zielgruppen oder Freigabebedürfnisse haben, können Sie Kontrollen auf Feldebene auf einen Datensatz stapeln oder die Daten aufteilen, in ein eigenes Objekt mit eigener Grenze. Ich teile nicht auf, nur um die Sicherheit auf Feldebene nicht konfigurieren zu müssen, aber Sicherheit ist ein legitimer Grund, das physische Modell zu ändern.

Die Freigabe hat ihre eigene Anzahl der Nullen

Zwei Entwürfe mit je 10 Millionen Datensätzen: der eine mit einfacher Eigentümerschaft, stabiler Hierarchie, wenigen Freigaberegeln und wenig Bewegung in den Mitgliedschaften; der andere mit stark verteilter Eigentümerschaft, häufig wechselnden Rollen, großen verschachtelten Gruppen, vielen Freigaberegeln und ständiger Umstrukturierung. Gleiche Anzahl Datensätze, völlig anderes Skalierungsproblem. Für jedes Objekt mit hohem Volumen will ich also auch die Zahlen des Zugriffsmodells: wie viele Eigentümer und wie stark geballt, der Standardzugriff, welche Hierarchiebeziehungen, Regeln und Gruppen zählen, wie viele externe Benutzer, und was passiert, wenn jemand die Rolle wechselt, ein Partner hinzukommt oder eine Region umstrukturiert wird. Dann eine Frage: Was ist die größte Neuberechnung, die dieser Entwurf auslösen könnte? Das ist das Szenario, das ich getestet sehen will.

Zum Vergrößern klicken

Count the access model, not just the records. ⟲

Optimieren Sie die Sicherheit nicht weg

There’s a dangerous conclusion to avoid: sharing is expensive, so make everything public. No. Performance isn’t an excuse to abandon a security requirement. Salesforce’s own guidance draws the line in the right place: “Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data” (same guide). Non-confidential data can be public; confidential data stays protected, and the design has to carry it. The job is an architecture that satisfies both: simpler ownership, more stable hierarchies, better group design, splitting data with different security needs, different relationships, planned realignments. “Private is slower, so make it public” is not an architecture strategy. ⟲

Über die Prüfung hinaus: Was KI ändert. Agenten rufen schneller ab und fassen schneller zusammen als jeder Mensch, was ein zu breites Zugriffsmodell gefährlicher macht. Verlassen Sie sich nicht auf einen Prompt, der sagt: „Zeige Redrock nicht die Daten von Brightwave.“ Die Grenze gehört in die Architektur: Die Autorisierung sollte begrenzen, was ein Agent erreichen kann, nicht Anweisungen, was er preiszugeben beschließt. Skalieren Sie das Autorisierungsmodell mit dem Datenmodell.

Was Architekt:innen hier entscheiden

• Welche Beziehungen, Eigentümer, Rollen, Gruppen und Freigaberegeln für jedes Objekt mit hohem Volumen den Zugriff steuern.
• Ob Eigentümer mit hohem Volumen und andere Hotspots von unbeständigen Hierarchie- und Gruppenstrukturen isoliert sind.
• Wie große Zugriffsneuausrichtungen getestet, geplant, einmal neu berechnet und mit Produktionsvolumen überprüft werden.
• Ob unterschiedliche Sicherheitsbedürfnisse es rechtfertigen, Daten aufzuteilen, statt den Zugriff auf einen Datensatz zu verkomplizieren.
• Wie der Zugriff von Partnern, Mitarbeitenden, Anwendungen und Agenten an Geschäftsbeziehungen gebunden bleibt, nicht an Abkürzungen über die Identität.

Es ist leicht, einen sicheren Entwurf für 1.000 Datensätze zu zeichnen, und einen schnellen, in dem alle alles sehen. Die Aufgabe der Architektur ist das System, in dem beides überlebt: Die richtigen Leute sehen die richtigen Daten, und es funktioniert noch, wenn wir die Nullen hinzufügen. Im großen Maßstab ist Freigabe Teil der Datenarchitektur.

Weiterlesen

• Object Reference for the Salesforce Platform, WorkOrderShare (öffnet in einem neuen Tab) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (öffnet in einem neuen Tab) (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (öffnet in einem neuen Tab), Group Membership Locking (öffnet in einem neuen Tab) and Deferred Sharing Maintenance (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Zur Vertiefung: der Kurs Sharing and Visibility Architect, Freigabe im großen Maßstab (coming soon).
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲
• Salesforce, Record-Level Access: Under the Hood (öffnet in einem neuen Tab) (Winter ‘27, archived copy (öffnet in einem neuen Tab)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (öffnet in einem neuen Tab) and Sharing a Record Using Apex (öffnet in einem neuen Tab), checked 2026-11-01. ⟲