Gdy wolumen spotyka model udostępniania

🌐 Dostępne także w 19 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku Ta sekcja zmieniła się w wersji angielskiej i nie została jeszcze ponownie przetłumaczona. (35)

Moduł 3 z 4 w rozdziale Projektowanie pod skalę, rozdziale 7 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Gorące punkty: nierównomierny rozkład własności, rekordów nadrzędnych i wyszukiwań · Dalej: Jeśli nie archiwizujesz dziś…

Pytanie, na które odpowiada ten moduł: jak model szanujący udostępnianie pozostaje szybki przy dużym wolumenie?

Poprzedni moduł znalazł gorące punkty. Teraz dodaj zabezpieczenia, czyli miejsce, w którym rozsądnie wyglądająca architektura danych robi się droga. Dziewięć milionów zleceń pracy to problem wolumenu. Dziewięć milionów zleceń pracy, z których każde jest widoczne dla dokładnie właściwych użytkowników wewnętrznych i dokładnie właściwego partnera detalicznego, to problem udostępniania przy dużym wolumenie. Rekord nie jest tylko przechowywany; Salesforce musi też odpowiedzieć na pytanie kto może go zobaczyć? W dużej skali ta odpowiedź jest częścią architektury danych.

Udostępnianie to też dane

Gdy architekci liczą wolumen, liczą rekordy biznesowe. Ale Salesforce utrzymuje też to, co wspiera dostęp: właścicieli, role, grupy, reguły udostępniania, jawne udostępnienia, członkostwa. W małej skali można zapomnieć, że ta praca istnieje. W dużej nie można. Dlatego nigdy nie mówię „zespół bezpieczeństwa ogarnie udostępnianie później”. Relacja, którą wybieram, właściciel, rekord nadrzędny, model użytkowników zewnętrznych: każde z nich wpływa na udostępnianie. Architekt danych i architekt udostępniania mogą być różnymi osobami, ale ich architektury są ze sobą połączone.

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 (otwiera się w nowej karcie); Sharing a Record Using Apex (otwiera się w nowej karcie)). 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 (otwiera się w nowej karcie), Winter ‘27, archived copy (otwiera się w nowej karcie)). 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 (otwiera się w nowej karcie)). 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. ⟲

Kliknij, aby powiększyć

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

Kliknij, aby powiększyć

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

Kliknij, aby powiększyć

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. ⟲

Zacznij od wymagania dostępu

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. ⟲

Hierarchia ról to nie schemat organizacyjny

Zespoły projektują hierarchię ról tak, by odzwierciedlała schemat organizacyjny. Potem firma się reorganizuje, ktoś przenosi rolę, a Salesforce musi wyliczyć konsekwencje dla dostępu. W małej skali nikt tego nie zauważa. Przy milionach rekordów reorganizacja to duża operacja na danych. Dlatego wytyczna dla właścicieli dużej liczby rekordów brzmi: bez roli albo osobna, stabilna rola na szczycie hierarchii (Ownership Data Skew (otwiera się w nowej karcie)). Zasada się uogólnia: w dużej skali stabilność jest cechą projektu. Im więcej rekordów zależy od struktury udostępniania, tym ostrożniej ją zmieniasz.

Z grupami jest tak samo. Grupy publiczne zasilają reguły udostępniania; użytkownicy należą do grup; grupy zawierają grupy. Przydatne narzędzia, ale jeśli ogromne populacje użytkowników i rekordów zależą od członkostwa w grupach, które ciągle się zmienia, musisz rozumieć przeliczanie. Dlatego właściciele dużej liczby rekordów pozostają poza grupami publicznymi używanymi jako źródła reguł udostępniania (to samo źródło). Lekcja nie brzmi „grupy publiczne są złe”. Brzmi: nie łącz największego skupiska rekordów z najbardziej zmiennymi strukturami dostępu bez przemyślenia sprawy.

Przeliczanie udostępniania to prawdziwa praca

Steve Trucking zmienia model działania: setki użytkowników się przenoszą, własność się zmienia, role i grupy się zmieniają, zmienia się duża reguła udostępniania. Brzmi jak konfiguracja. Ale platforma może musieć przeliczyć dostęp w dużej populacji rekordów, więc traktuję to jako operację na danych. Ilu użytkowników, rekordów, zmian własności i członkostwa? Ile przeliczania? Czy możemy to przetestować przy prawdziwym wolumenie? Kiedy to uruchomić i co w tym czasie widzą użytkownicy? Duża przebudowa zabezpieczeń zasługuje na tę samą dyscyplinę co duża migracja danych.

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 (otwiera się w nowej karcie)). 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 (otwiera się w nowej karcie), 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. ⟲

Kliknij, aby powiększyć

At scale, access realignment is a data operation. ⟲

„Odroczone” nie znaczy „na luzie”. Jeśli zmiana jest na tyle duża, żeby odraczać udostępnianie, chcę planu: przetestowanego przy realistycznym wolumenie, okna serwisowego zaakceptowanego przez biznes, weryfikacji, planu awaryjnego, jeśli się nie skończy, i zrozumienia, czego w tym czasie doświadczą użytkownicy. Wytyczna Salesforce to najpierw zamodelować to w sandboxie z pełną kopią (full copy sandbox; to samo źródło), bo model zabezpieczeń, który pięknie działa przy 5000 rekordów testowych, niczego nie dowodzi w odniesieniu do 50 milionów. Testuj Liczbę Zer, dla której naprawdę projektujesz.

Blokowanie granularne pomaga, ale nie leczy

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 (otwiera się w nowej karcie)); 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: izolacja partnerów w dużej skali

W Punkcie kontrolnym 1 każde zlecenie pracy trwale nosi swojego partnera detalicznego, bo izolacja partnerów to wymaganie. Liczby skali czynią to ważniejszym, nie mniej ważnym: jeśli Redrock to 40% biznesu, to w ciągu pięciu lat około 3,6 miliona zleceń pracy Redrock. Relacja jest poprawna; Redrock naprawdę jest jednym partnerem. Projekt dostępu musi więc iść za prawdziwą relacją biznesową (użytkownicy partnera widzą zlecenia swojego partnera, kierownicy CD tylko swojego CD), zamiast zniekształcać model. Struktura kont podrzędnych dla każdego CD z poprzedniego modułu pomaga tu podwójnie: rozkłada rekordy podrzędne i daje dostępowi na poziomie CD coś prawdziwego, do czego można go przypiąć.

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. ⟲

Dostęp wewnętrzny to jeszcze inna sprawa

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. ⟲

Czasem zabezpieczenia powinny zmienić model. Gdy dwa rodzaje informacji mają zupełnie różnych właścicieli, cykle życia, odbiorców lub potrzeby udostępniania, możesz nakładać kontrole na poziomie pól na jeden rekord albo wydzielić dane do osobnego obiektu z własną granicą. Nie wydzielam tylko po to, żeby uniknąć konfiguracji zabezpieczeń na poziomie pól, ale bezpieczeństwo to uzasadniony powód do zmiany modelu fizycznego.

Udostępnianie ma własną Liczbę Zer

Dwa projekty, każdy z 10 milionami rekordów: jeden z prostą własnością, stabilną hierarchią, kilkoma regułami udostępniania i małą rotacją członkostwa; drugi z bardzo rozproszoną własnością, często zmieniającymi się rolami, dużymi zagnieżdżonymi grupami, wieloma regułami udostępniania i ciągłą reorganizacją. Ta sama liczba rekordów, zupełnie inny problem skali. Dlatego dla każdego obiektu o dużym wolumenie chcę też liczb modelu dostępu: ilu właścicieli i jak bardzo skoncentrowanych, dostęp domyślny, które relacje w hierarchii, reguły i grupy mają znaczenie, ilu użytkowników zewnętrznych i co się dzieje, gdy ktoś zmienia rolę, dochodzi partner albo region jest reorganizowany. Potem jedno pytanie: jakie największe przeliczenie może wywołać ten projekt? To scenariusz, który chcę przetestować.

Kliknij, aby powiększyć

Count the access model, not just the records. ⟲

Nie optymalizuj kosztem bezpieczeństwa

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. ⟲

Poza egzaminem: co zmienia AI. Agenci pobierają i agregują szybciej niż jakikolwiek człowiek, co czyni zbyt szeroki model dostępu bardziej niebezpiecznym. Nie polegaj na prompcie mówiącym „nie pokazuj danych Brightwave firmie Redrock”. Granica należy do architektury: to autoryzacja powinna ograniczać, do czego agent może sięgnąć, a nie instrukcje, co zdecyduje się ujawnić. Skaluj model autoryzacji razem z modelem danych.

Co tu decyduje architekt

• Które relacje, właściciele, role, grupy i reguły udostępniania sterują dostępem w każdym obiekcie o dużym wolumenie.
• Czy właściciele dużej liczby rekordów i inne gorące punkty są odizolowani od zmiennych struktur hierarchii i grup.
• Jak duże przebudowy dostępu są testowane, planowane, przeliczane raz i weryfikowane przy produkcyjnym wolumenie.
• Czy różne potrzeby bezpieczeństwa uzasadniają wydzielenie danych zamiast komplikowania dostępu do jednego rekordu.
• Jak dostęp partnerów, pracowników, aplikacji i agentów pozostaje związany z relacjami biznesowymi, a nie ze skrótami przez tożsamość.

Łatwo narysować bezpieczny projekt dla 1000 rekordów i szybki projekt, w którym wszyscy widzą wszystko. Zadaniem architekta jest system, w którym przetrwa jedno i drugie: właściwe osoby widzą właściwe dane, a całość nadal działa, gdy dodamy zera. W dużej skali udostępnianie jest częścią architektury danych.

Do zgłębienia

• Object Reference for the Salesforce Platform, WorkOrderShare (otwiera się w nowej karcie) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (otwiera się w nowej karcie) (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 (otwiera się w nowej karcie), Group Membership Locking (otwiera się w nowej karcie) and Deferred Sharing Maintenance (otwiera się w nowej karcie), checked 2026-11-01. ⟲
• Dla pogłębienia: kurs Sharing and Visibility Architect, Udostępnianie w dużej skali (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 (otwiera się w nowej karcie) (Winter ‘27, archived copy (otwiera się w nowej karcie)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (otwiera się w nowej karcie) and Sharing a Record Using Apex (otwiera się w nowej karcie), checked 2026-11-01. ⟲