Власність і життєвий цикл

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

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) · Deutsch (Schweiz)

The cut end of a large log in a forest, every year's growth ring visible from the center to the bark. — Зображення згенеровано ШІ

Модуль 8 з 10 розділу Архітектура даних Salesforce, розділ 3 курсу Data Architect. Кожен модуль самостійний. Попередній: Зв’язки мають наслідки · Наступний: Як зберігати дані узгодженими

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

Дивлячись на модель даних, я хочу знати не лише, які є об’єкти і як вони пов’язані. Я хочу знати, що відбувається із записами з часом. Хто їх створює? Хто ними володіє? Хто може їх перепризначити? Що відбувається, коли бізнес-відносини змінюються, коли записи вже не активні? Чи слід їх колись видаляти і як довго ми їх зберігаємо? Нічого з цього не видно на ERD, діаграмі «сутність–зв’язок»: прямокутниках і лініях моделі даних із розділу 2. Усе це — архітектура даних. А в Salesforce власність — це місце, де модель даних і модель безпеки стикаються.

Власність — це більше, ніж ім’я в полі

Адміністратори бачать у записі Owner і читають його як мітку: Bart володіє цим акаунтом, Lisa — тим зверненням. Це може означати й таке. Але в Salesforce власність — це ще й механізм платформи. В об’єктах, що мають власника, власник визначає, хто може бачити запис, через ієрархію ролей, правила спільного доступу, черги й перепризначення. Тож коли я питаю «хто володіє цим записом?», я не питаю, чиє ім’я стоїть на сторінці. Я питаю, яку поведінку безпеки й життєвого циклу ми до нього прив’язуємо. Власником може бути користувач або, для деяких об’єктів, серед них користувацькі об’єкти, звернення й ліди, черга, і в будь-якому разі власник отримує повний доступ до запису (Understanding Sharing (opens in a new tab)).

Тому я розділяю бізнес-відповідальність і власність запису. Іноді це та сама людина. Іноді — ні. Якщо бізнес каже, що за доставку відповідає диспетчер, це не робить диспетчера власником автоматично. Відповідальність може жити у власному полі, а власність — налаштовуватися так, щоб підтримувати безпеку й масштаб. Не дозволяйте їх плутати лише тому, що обидва англійською звуться «owner».

Таблиця спільного доступу: де власність стає доступом

Дехто навіть не знає, що таке таблиця спільного доступу. Кожен архітектор даних має знати.

Більшість спільного доступу до запису зберігається в пов’язаному об’єкті спільного доступу (share object) — версії списку контролю доступу від Salesforce (Understanding Sharing (opens in a new tab)). В Account є AccountShare, у Contact — ContactShare, а користувацький об’єкт отримує власний: у Truck__c є Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Кожен рядок у ньому каже чотири речі:

Який запис: батьківський ID.
Хто: користувач або група (публічна група, група ролі, територія).
Скільки: Read, Edit або All (повний доступ).
Чому: причина рядка (row cause). Owner для власника, Rule для правила спільного доступу, Manual для ручного спільного доступу, Team, неявні причини, які Salesforce додає між акаунтом і його дочірніми записами, і причини, які розробник визначає для Apex sharing.

На заняттях я відкриваю Workbench і запитую таблицю спільного доступу, поки ділюся записом, і ви бачите, як рядки з’являються й зникають. Коли хтось питає «чому ця людина бачить те?», відповідь часто лежить у рядку разом зі своєю причиною.

Але не все там є. Налаштування за замовчуванням для організації — це не рядок. Ієрархія ролей там теж не зберігається: доступ для людей над власником обчислюється тоді, коли потрібен. А View All, Modify All, View All Data і Modify All Data повністю оминають таблицю спільного доступу (Sharing a Record Using Apex (opens in a new tab)). Як я кажу на заняттях: поставте прапорець View All — і ви оминули таблицю спільного доступу.

Деякими записами Salesforce ділиться й за вас — через те, як вони пов’язані. Це неявний спільний доступ, і він працює між акаунтом і його дочірніми записами. Якщо ви бачите контакт, звернення чи можливість, ви можете також читати акаунт, якому вони належать. А власник акаунта отримує доступ до контактів, звернень і можливостей акаунта на рівні, заданому роллю власника (Implicit Sharing (opens in a new tab)). В останніх релізах Salesforce частину цього дочірнього доступу обчислює тоді, коли потрібно, замість зберігати його рядками, тож не дивуйтеся, коли запит до таблиці спільного доступу його не покаже. Тут я лише натякаю; подробиці — у розділі Зв’язки і вбудований спільний доступ.

Ще один виняток — для випадків, коли у вас багато зовнішніх користувачів. Користувачі спільнот із великим обсягом (high-volume community users), ліцензії Customer Community, створені для тисяч і мільйонів клієнтів, не мають ролі, не можуть бути в публічних групах, і їм не можна надати записи через правила спільного доступу чи ручний спільний доступ (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). Для них таблиця спільного доступу — не відповідь: вони дістаються до записів через sharing sets (набори спільного доступу), які зіставляють акаунт чи контакт запису з акаунтом чи контактом самого користувача. Це одна з причин, чому ці ліцензії масштабуються. Курс Sharing and Visibility розглядає це в розділі Спільний доступ для зовнішніх користувачів.

І пам’ятайте модуль 7: detail-об’єкт узагалі не має об’єкта спільного доступу. Його доступ іде від об’єкта спільного доступу master і від Sharing Setting у полі master-detail.

Чому це важливо архітекторові даних? Бо власність записана в цій таблиці. Кожна зміна власника, кожне нове правило спільного доступу, кожен користувач, що переходить між ролями чи групами, означає, що Salesforce додає й прибирає рядки. На кількох тисячах записів ніхто не помічає. На десяти мільйонах, коли більшістю з них володіє один користувач, — це той перерахунок, з яким ми зараз зустрінемося.

Варто знати для іспиту. Об’єкт спільного доступу користувацького об’єкта називається Object__Share, як-от Truck__Share. Detail-об’єкт не має об’єкта спільного доступу: його доступ іде від master. А коли змінюється власник запису, його ручний спільний доступ прибирається, тоді як Apex sharing із власною причиною розробника лишається.

Тут модель даних передає естафету моделі безпеки, і решту я викладаю в курсі Sharing and Visibility Architect: 22 способи поділитися записом від Steve, Org-wide defaults, власність, черги та ієрархія ролей, Зв’язки і вбудований спільний доступ про неявний спільний доступ і Програмний спільний доступ і безпечний код про причини Apex sharing. У цьому курсі розділ 12 зводить усе це разом для людей, застосунків і агентів.

Іноді власність успадковується

У попередньому модулі ми бачили, що дочірній запис master-detail не має власного власника; він слідує за батьківським. Часто це саме те, що треба. Чи потрібен бізнесу окремий власник для кожної позиції доставки? Ні. Доставка володіє життєвим циклом, а позиція належить їй. Ось чому проєктування зв’язків і проєктування власності відбуваються разом: обравши master-detail, ви вже ухвалили частину рішення про власність.

Хто володіє записами, які створюють системи?

Тепер стає цікаво. Людина створює акаунт і, можливо, стає його власником. Але ERP надсилає за ніч 100 000 транзакцій. Хто ними володіє? Інтеграційний користувач? Черга? Регіональний власник, визначений за даними? Системний акаунт, про який ніхто не думав п’ять років? А тепер записи створюють ще й агенти.

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

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

Власність може стати проблемою масштабу

Розподіл теж важливий. Десять мільйонів записів, розподілених між тисячами власників, — це одна форма. Десять мільйонів записів, що належать одному користувачеві, — зовсім інша. Salesforce називає це перекосом власності (ownership data skew), коли один користувач володіє понад 10 000 записів об’єкта (Ownership Data Skew (opens in a new tab)). Зазвичай так буває, коли хтось паркує все на одному користувачі чи черзі: усі непризначені ліди — на користувачі-заглушці, кожен інтеграційний запис — на інтеграційному користувачі. Це нешкідливо, доки цей користувач не переміститься в ієрархії ролей або не ввійде чи не вийде з групи, від якої залежить правило спільного доступу. Тоді Salesforce мусить змінити величезну кількість записів спільного доступу, і ви отримуєте тривалі перерахунки.

Рекомендації практичні. Де можете, розподіляйте власність між більшою кількістю користувачів. Якщо один користувач мусить володіти багатьма записами, тримайте його поза ієрархією ролей; якщо йому потрібна роль, дайте йому окрему роль на самій вершині і не переміщуйте його, а також тримайте його поза публічними групами, які використовують правила спільного доступу (Ownership Data Skew (opens in a new tab)). Те саме мислення застосовується до батьківського запису з надто великою кількістю дочірніх із попереднього модуля — перекосу «батьківський–дочірній» (parent-child skew).

Отже, розподіл — частина фізичної моделі. Питайте не лише, скільки записів, а й як вони розподілені. Це ще одна версія «кількості нулів»: не лише скільки нулів, а й де ці нулі зосереджені. Частина 2 розглядає перекіс глибоко; тут я хочу, щоб ви бачили його наближення. Курс Sharing and Visibility повертається до цього в розділі Sharing at Scale.

«Власник за замовчуванням» стає архітектурою

Ось шаблон, який я бачу постійно. Ніхто не знає, хто має чимось володіти, тож хтось каже: «Просто призначте все інтеграційному користувачеві» або «створіть загального користувача System». Можливо, це правильно. Але не робіть цього випадково. Тимчасове значення за замовчуванням має звичку ставати постійним: через два роки кожен запис належить integration@company.com, ніхто не пам’ятає чому, а змінити це — цілий проєкт. Це тест на зворотність із розділу 1: перш ніж віддати мільйон записів одному власникові, спитайте, чого коштуватиме змінити це пізніше.

Перепризначення — це подія життєвого циклу

Власники змінюються. Менеджери звільняються, території зміщуються, команди реорганізуються, регіони перебалансовуються. Що залежить від власника: спільний доступ, автоматизація, звіти, черги, ескалації, інтеграції? Якщо зміна власника змінює, хто може бачити запис, перепризначення — це не адміністративне прибирання. Це подія безпеки, а на мільйоні записів — ще й операційна. Стежте за таблицею спільного доступу, коли це стається: ручний спільний доступ прибирається, коли змінюється власник, тоді як Apex sharing із власною причиною розробника переживає цю зміну (Understanding Sharing (opens in a new tab)). На заняттях я ділюся записом із кимось, змінюю власника — і людина втрачає доступ. Аудиторія щоразу дивується.

І пам’ятайте, що власність — не те саме, що доступ. Власник — не єдина людина, якій треба бачити запис, і Salesforce має багато способів надати доступ: ієрархія ролей, правила спільного доступу, команди, території, ручний і програмний спільний доступ. Курс Sharing and Visibility розглядає їх глибоко, починаючи з розділу 22 способи поділитися записом від Steve. Думка архітектора простіша: не використовуйте власність, щоб розв’язувати кожну проблему доступу. Якщо ви переставляєте власників лише для того, щоб хтось побачив запис, ви, мабуть, розв’язуєте не ту проблему.

Створення — це лише початок

Багато моделювання даних зупиняється на створенні: поля, об’єкт, зв’язок — готово. Але запис може жити десять років. Його оновлюють, у нього змінюються власники, статус і зв’язки, він стає неактивним, перетворюється на історію, може потребувати архівування, а колись, можливо, видалення. Архітектура — це не лише те, як запис народжується. Це те, що відбувається від народження до смерті.

Click to enlarge

Не видаляйте лише тому, що щось старе

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

Зберігання — це бізнес-вимога

Інший бік: зберігати все вічно — теж не архітектура. Сховище росте, звіти сповільнюються, пошук стає шумнішим, а закон про приватність може вимагати, щоб частину даних прибрали. Тож я хочу явної відповіді на питання як довго ми це зберігаємо? «Salesforce це зберігає» — не політика зберігання.

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

Я роками кажу це на заняттях: якщо ви не архівуєте сьогодні, чи будете ви колись архівувати? «Розберемося пізніше» має звичку ставати аварійним проєктом на трьохстах мільйонах записів. У частині 2 є цілий модуль про архівування й очищення, побудований на тому самому запитанні.

Steve Trucking: хто володіє доставкою?

Доставку створює інтеграція з маніфесту роздрібного партнера, приблизно 3 300 разів на день. Хто нею володіє? Не роздрібний партнер — це бізнес-відносини. Не отримувач. Бригада її виконує, але чи має запис змінювати власника щоразу, коли бригади міняються вантажівками? Диспетчер? Розподільчий центр? Черга? Інтеграційний користувач, що її створив?

Тепер застосуйте цей модуль, почавши з питання, яке все вирішує: чи визначає власність чийсь доступ до доставок? У Steve Trucking — ні. Диспетчери бачать доставки свого розподільчого центру, бригади — ті, що на їхніх маршрутах, а кожен роздрібний продавець бачить свої на партнерському порталі. Ніщо з цього не залежить від того, хто володіє записом; усе йде від розподільчого центру, маршруту й партнера.

Тож моя відповідь: доставками володіє інтеграційний користувач. Це добрий приклад того, як системний користувач свідомо володіє записами:

Аудиторський слід чесний. Власник кожної доставки каже, звідки вона прийшла: з інтеграції маніфестів.
Доступ іде від спільного доступу, а не від власності. Правила спільного доступу на основі критеріїв за розподільчим центром дають команді кожного DC її доставки; партнери дістаються до своїх через портал.
Перекіс прибрано на рівні дизайну. При 3 300 на день інтеграційний користувач перевищить 10 000 доставок за три дні, тож це перекіс власності з першого дня, і це нормально, якщо ми це запланували. Інтеграційний користувач не має ролі, тож нічого над ним в ієрархії не треба перераховувати, і він лишається поза публічними групами, які використовують наші правила спільного доступу.
Ніхто не перепризначає доставки. Бригади міняються вантажівками, диспетчери — змінами, а власник не змінюється ніколи, тож немає бурі перепризначень і немає ручного спільного доступу, який можна втратити.

І запишіть, що станеться, якщо цього користувача колись деактивують чи замінять, бо тепер він володіє мільйонами записів. Саме це рішення шукатиме наступна команда.

За межами іспиту: що змінює ШІ. Агенти створюють і змінюють записи з машинною швидкістю. Якщо агент створить 100 000 записів під власним користувачем, «виправимо власника пізніше» перетворюється на перекіс, перерахунок спільного доступу і проєкт із прибирання. Визначте правило власності для агента до запуску, поставивши те саме питання: чи має тут власність значення для спільного доступу?

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

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

Дивлячись на фізичну модель, питайте не лише, де зберігаються дані. Питайте, хто володіє ними сьогодні, хто може володіти завтра і що станеться, коли вони нам більше не потрібні. Далі: навіть із правильним об’єктом, полями, зв’язками й власником дані ще мають лишатися надійними.

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

Apex Developer Guide, Understanding Sharing (opens in a new tab) (англійською, перевірено 2026-10-13): власники (користувач або черга для користувацьких об’єктів, звернень і лідів) отримують повний доступ; більшість спільного доступу живе в пов’язаному об’єкті спільного доступу; ієрархія ролей обчислюється під час виконання; ручний спільний доступ прибирається, коли змінюється власник, Apex managed sharing зберігається; значення row cause.
Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (англійською, перевірено 2026-10-13): AccountShare, MyCustomObject__Share; detail-об’єкти не мають об’єкта спільного доступу; чого не відстежує об’єкт спільного доступу (OWD, ієрархія ролей, View All і Modify All).
Salesforce Help, Implicit Sharing (opens in a new tab) (англійською, перевірено 2026-10-13): доступ між акаунтом і його контактами, зверненнями й можливостями.
Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) і Sharing Rule Considerations (opens in a new tab) (англійською, перевірено 2026-10-13): без ролей, без правил спільного доступу чи ручного спільного доступу; натомість sharing sets.
Курс Sharing and Visibility Architect: 22 способи поділитися записом від Steve, Org-wide defaults, власність, черги та ієрархія ролей, Зв’язки і вбудований спільний доступ, Програмний спільний доступ і безпечний код, Спільний доступ для зовнішніх користувачів, Sharing at Scale.
Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) і Parent-Child Data Skew (opens in a new tab) (англійською, перевірено 2026-10-02).