Обсяг зустрічає модель спільного доступу

🌐 Також доступно 19 мовами

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

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською Цей розділ змінився англійською і ще не перекладений заново. (35)

Модуль 3 з 4 розділу Проєктування для масштабу, розділ 7 курсу Data Architect. Кожен модуль самостійний. Попередній: Гарячі точки: перекіс власності, батьківських записів і lookup · Наступний: Якщо ви не архівуєте сьогодні…

Питання, на яке відповідає цей модуль: Як модель, що поважає спільний доступ, залишається швидкою на великих обсягах?

Попередній модуль знайшов гарячі точки. Тепер додайте безпеку — тут розумна на вигляд архітектура даних стає дорогою. Дев’ять мільйонів робочих замовлень — це задача обсягу. Дев’ять мільйонів робочих замовлень, кожне з яких бачать рівно ті внутрішні користувачі й рівно той роздрібний партнер, що потрібно, — це задача спільного доступу на великих обсягах. Запис не просто зберігається; Salesforce ще мусить відповісти, хто може його бачити? У масштабі ця відповідь — частина архітектури даних.

Спільний доступ — теж дані

Коли архітектори рахують обсяг, вони рахують бізнес-записи. Але Salesforce також підтримує те, що забезпечує доступ: власників, ролі, групи, правила спільного доступу, явні надання доступу, членства. На малому масштабі можна забути, що ця робота існує. На великому — не можна. Ось чому я ніколи не кажу «команда безпеки потім розбереться зі спільним доступом». Зв’язок, який я обираю, власник, батьківський запис, модель зовнішніх користувачів — кожне з цього впливає на спільний доступ. Архітектор даних і архітектор спільного доступу можуть бути різними людьми, але їхні архітектури пов’язані.

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 (відкривається в новій вкладці); Sharing a Record Using Apex (відкривається в новій вкладці)). 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 (відкривається в новій вкладці), Winter ‘27, archived copy (відкривається в новій вкладці)). 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 (відкривається в новій вкладці)). 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. ⟲

Натисніть, щоб збільшити

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

Натисніть, щоб збільшити

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

Натисніть, щоб збільшити

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

Почніть із вимоги до доступу

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

Ієрархія ролей — не оргсхема

Команди проєктують ієрархію ролей як дзеркало оргсхеми. Потім компанія реорганізовується, хтось переміщує роль, і Salesforce доводиться прораховувати наслідки для доступу. На малому масштабі ніхто не помічає. На мільйонах записів реорганізація — це велика операція з даними. Ось чому настанова для власників великих обсягів — без ролі, або окрема стабільна роль на вершині ієрархії (Ownership Data Skew (відкривається в новій вкладці)). Принцип узагальнюється: у масштабі стабільність — це властивість проєкту. Що більше записів висить на структурі спільного доступу, то обережніше ви її змінюєте.

З групами так само. Публічні групи живлять правила спільного доступу; користувачі належать до груп; групи містять групи. Корисні інструменти, але якщо величезна кількість користувачів і записів залежить від членства в групах, яке постійно змінюється, вам треба розуміти перерахунок. Ось чому власники великих обсягів залишаються поза публічними групами, які використовують як джерела правил спільного доступу (те саме джерело). Урок не в тому, що «публічні групи погані». Урок такий: не підключайте свою найбільшу концентрацію записів до найнестабільніших структур доступу, не подумавши як слід.

Перерахунок спільного доступу — справжня робота

Steve Trucking змінює операційну модель: сотні користувачів переходять, власність змінюється, ролі й групи змінюються, змінюється велике правило спільного доступу. Звучить як налаштування. Але платформі, можливо, доведеться перерахувати доступ для великої кількості записів, тож я ставлюся до цього як до операції з даними. Скільки користувачів, записів, змін власності й членства? Скільки перерахунку? Чи можемо ми протестувати це на реальному обсязі? Коли це запускати і що бачать користувачі тим часом? Велика перебудова безпеки заслуговує на таку саму дисципліну, як велика міграція даних.

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 (відкривається в новій вкладці)). 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 (відкривається в новій вкладці), 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. ⟲

Натисніть, щоб збільшити

At scale, access realignment is a data operation. ⟲

«Відкладені» не означає «недбалі». Якщо зміна настільки велика, що спільний доступ треба відкласти, я хочу план: тест на реалістичному обсязі, вікно обслуговування, погоджене з бізнесом, перевірка, запасний варіант, якщо не встигне завершитися, і розуміння того, що бачать користувачі тим часом. Настанова Salesforce — спершу змоделювати це у full copy sandbox (те саме джерело), бо модель безпеки, яка чудово працює з 5 000 тестових записів, нічого не доводить щодо 50 мільйонів. Тестуйте ту «кількість нулів», для якої ви справді проєктуєте.

Гранулярне блокування допомагає, але це не ліки

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 (відкривається в новій вкладці)); 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: ізоляція партнерів у масштабі

На Контрольній точці 1 кожне робоче замовлення стійко несе свого роздрібного партнера, бо ізоляція партнерів — вимога. Числа масштабу роблять це важливішим, а не менш важливим: якщо Redrock дає 40% бізнесу, це приблизно 3,6 мільйона робочих замовлень Redrock за п’ять років. Зв’язок правильний; Redrock справді один партнер. Тож проєкт доступу має йти за справжнім бізнесовим зв’язком (користувачі партнера бачать робочі замовлення свого партнера, менеджери DC — лише свого DC), а не спотворювати модель. Структура «дочірній акаунт на кожен DC» з попереднього модуля тут допомагає двічі: вона розподіляє дочірні записи і дає доступу на рівні DC справжню опору.

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

Внутрішній доступ — знову інший

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

Іноді безпека має змінювати модель. Коли два види інформації мають зовсім різних власників, життєві цикли, аудиторії чи потреби спільного доступу, можна нагромадити контроль на рівні полів на одному записі, а можна розділити дані в окремий об’єкт із власною межею. Я не розділяю лише для того, щоб не налаштовувати безпеку на рівні полів, але безпека — законна причина змінити фізичну модель.

У спільного доступу своя «кількість нулів»

Два проєкти по 10 мільйонів записів: один із простою власністю, стабільною ієрархією, кількома правилами спільного доступу й малою плинністю членства; інший із сильно розподіленою власністю, ролями, що часто змінюються, великими вкладеними групами, багатьма правилами спільного доступу й постійними реорганізаціями. Однакова кількість записів, зовсім різна задача масштабу. Тож для кожного об’єкта з великим обсягом я хочу бачити й числа моделі доступу: скільки власників і наскільки вони сконцентровані, доступ за замовчуванням, які зв’язки в ієрархії, правила й групи мають значення, скільки зовнішніх користувачів і що відбувається, коли хтось змінює роль, додають партнера чи реорганізують регіон. А потім одне запитання: який найбільший перерахунок може спричинити цей проєкт? Саме цей сценарій я хочу протестувати.

Натисніть, щоб збільшити

Count the access model, not just the records. ⟲

Не оптимізуйте безпеку до нуля

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

За межами іспиту: що змінює ШІ. Агенти отримують і агрегують дані швидше за будь-яку людину, і через це надто широка модель доступу стає небезпечнішою. Не покладайтеся на промпт, що каже «не показуй дані Brightwave для Redrock». Межа належить архітектурі: авторизація має обмежувати те, до чого агент може дістатися, а не інструкції — те, що він вирішить розкрити. Масштабуйте модель авторизації разом із моделлю даних.

Що тут вирішує архітектор

• Які зв’язки, власники, ролі, групи й правила спільного доступу керують доступом до кожного об’єкта з великим обсягом.
• Чи ізольовані власники великих обсягів та інші гарячі точки від нестабільних структур ієрархії й груп.
• Як великі перебудови доступу тестують, планують, перераховують один раз і перевіряють на виробничому обсязі.
• Чи виправдовують різні потреби безпеки розділення даних замість ускладнення доступу до одного запису.
• Як доступ партнерів, працівників, застосунків і агентів залишається прив’язаним до бізнесових зв’язків, а не до коротких шляхів через ідентичність.

Легко намалювати безпечний проєкт для 1 000 записів і швидкий, де всі бачать усе. Завдання архітектора — система, у якій виживає і те, і те: потрібні люди бачать потрібні дані, і все працює, коли ми додаємо нулі. У масштабі спільний доступ — частина архітектури даних.

Додаткові матеріали

• Object Reference for the Salesforce Platform, WorkOrderShare (відкривається в новій вкладці) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (відкривається в новій вкладці) (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 (відкривається в новій вкладці), Group Membership Locking (відкривається в новій вкладці) and Deferred Sharing Maintenance (відкривається в новій вкладці), checked 2026-11-01. ⟲
• Для глибшого занурення: курс Sharing and Visibility Architect, Спільний доступ у масштабі (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 (відкривається в новій вкладці) (Winter ‘27, archived copy (відкривається в новій вкладці)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (відкривається в новій вкладці) and Sharing a Record Using Apex (відкривається в новій вкладці), checked 2026-11-01. ⟲