Як зберігати дані узгодженими

🌐 Також доступно 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)

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

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 9 з 10 розділу Архітектура даних Salesforce, розділ 3 курсу Data Architect. Кожен модуль самостійний. Попередній: Власність і життєвий цикл · Наступний: Спроєктуйте фізичну модель Salesforce

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

Усі хочуть чистих даних. Я жодного разу не бачив зустрічі з вимог, де хтось сказав би: «Насправді ми хотіли б неузгоджених даних». Розбіжність з’являється пізніше: де ми забезпечуємо правила? На екрані? Обов’язкове поле? Список вибору, правило перевірки, правило дублікатів, flow, Apex? Усе це допомагає. Але вони не взаємозамінні, і кожен рівень має свою ціну.

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

Щабель перший: тип поля і словник

Перше правило узгодженості — те, що з модуля 6: оберіть правильний тип. Дата — це Date, момент часу — Date/Time, гроші — Currency. Це узгодженість ще до того, як хтось напише правило.

Зробіть статус доставки текстовим полем — і отримаєте Delivered, delivered, DELIVERED, Complete, Done і Dropped off, а комусь доведеться з’ясовувати, чи означають ці шість одне й те саме. Або визначте словник один раз: Delivered, одне значення, один зміст. Зробіть його обмеженим списком вибору, щоб він відхиляв усе, чого немає в списку, навіть через API, і глобальним набором значень, коли кілька полів спільно використовують список (подробиці в модулі 6).

Але не використовуйте список вибору лише для того, щоб люди не вводили текст. Це справді значення, чи інша сутність? Дев’ять розподільчих центрів, кожен із назвою, можуть виглядати як список вибору; дев’ять з адресами, керівниками, потужністю й вантажівками — це записи. Правило має підсилювати модель, а не компенсувати погану. А якщо це справді контрольований словник, контролюйте його на рівні поля. Не допускайте хаосу, щоб потім будувати flow, який перетворює AZ, Arizona, Ariz і Phoenix area на значення, яке ви хотіли з самого початку.

Щабель другий: Required і Unique

Required і Unique привабливі, бо прості: поставив прапорець — проблему розв’язано. Іноді. Якщо кожна вантажівка має парковий номер із дня створення і жодні дві вантажівки не мають спільного, обидва прапорці виражають реальні бізнес-правила. Це сильна узгодженість.

Але щойно платформа забезпечує правило, їй байдуже, що у вашому процесі є виняток у вівторок по обіді. Я роками використовую цей приклад на заняттях. Об’єкт існує вже давно, у ньому купа записів. Хтось додає поле й позначає Required. Тестує створення запису: працює чудово. Потім суботній вечір, розгортання, запускаються тести, і старий тестовий клас створює об’єкт без нового поля. Бум. Або хтось редагує старий запис, створений до появи поля. Або інтеграція надсилає той самий payload, що й п’ять років поспіль. Бум. «Але ж ми не змінювали це поле». Платформі байдуже: ви змінили контракт того, що таке коректний запис. Нове правило впливає не лише на нові дані; воно змінює те, що можна робити зі старими.

Щабель третій: правила перевірки

Правила перевірки дають змогу казати набагато багатші речі. Якщо статус Delivered, фактичний час доставки має бути заповнений. Якщо зупинка — це монтаж, чекліст має бути заповнений, перш ніж зупинку можна закрити. Вони спрацьовують під час збереження запису, тож захищають запис незалежно від того, чи його зберегли зі сторінки, через API, завантаження даних, інтеграцію чи агента. У цьому суть. Якщо правило має захищати запис, ставте його там, де його зустріне кожен запис даних.

А ще в них є зуби. Це і їхня сила, і їхня ціна.

Проблема старих записів

Ось де стає неприємно. У вас мільйон записів, і сьогодні ви додаєте правило: час доставки не може бути раніше за виїзд маршруту. Розумно. Але двадцять тисяч старих записів його порушують — завдяки міграції семирічної давнини. Користувач відкриває один із них і змінює номер телефону. Зберегти. Правило спрацьовує. «Я змінив номер телефону. Чому ви кажете мені про час доставки з 2019 року?» Слушне питання.

Тож правило перевірки має казати не лише, що має бути правдою. Воно має казати, коли це забезпечувати. Функції на кшталт ISNEW() і ISCHANGED() дають змогу обмежити правило новими записами або збереженнями, де відповідні поля справді змінюються (Validation Rule Considerations (opens in a new tab)).

Але запис змінюється не лише тоді, коли його редагує людина, і багато причин поза вашим контролем. Інтеграція вночі оновлює статус. Flow проставляє дату. Менеджер перепризначає територію, і власник змінюється на десяти тисячах записів. Хтось редагує позицію доставки, зведення в доставці перераховується, і це зберігає доставку, тож правило перевірки доставки спрацьовує для користувача, який її навіть не торкався (Roll-Up Summary Field (opens in a new tab) попереджає, що помилки перевірки можуть з’явитися на detail або на master). Кожне з цих збережень зустрічається з вашим новим правилом. Тож для кожного нового правила питайте: чи має це правило застосовуватися до цього збереження?

Ось варіанти, і ви вплітаєте їх у правило:

• Завжди, при кожному збереженні. Правильно, коли правило справді про запис, а старі дані його проходять. Але знайте, що означає «кожне збереження»: пакетне завдання, яке лише змінює власника, чи будь-яке дрібне редагування будь-якого поля в записі теж мусить його пройти.
• Лише для нових записів, з ISNEW(). Правило перевіряє запис один раз, під час створення, і більше ніколи. Минуле лишається як було, але й майбутнє теж: пізніше редагування може змусити новий запис порушити правило, і ніхто цього не зупинить. Якщо це важливо, поєднайте з наступним варіантом.
• Лише коли змінюються поля, яких воно стосується, з ISCHANGED(). Редагування номера телефону не будить правило про час доставки.
• Не для певних авторів змін. Користувацький дозвіл (custom permission), перевірений у формулі як $Permission, пропускає інтеграційного користувача чи міграцію даних, тоді як люди й далі проходять правило (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Надавайте його свідомо й небагатьом.
• Від певної дати, порівнюючи CreatedDate із днем, коли правило запрацювало, коли «новий» означає «відтоді, як ми почали це вимагати». На відміну від ISNEW(), воно перевіряє ці записи й при кожному наступному збереженні, тож те саме попередження діє: дрібна зміна, як-от пакетне оновлення власника, може не пройти на записі, що з часом відхилився.

Додаєте правило до записів, які у вас уже є? Продумайте наслідки, перш ніж його вмикати. Кожен наявний запис тепер мусить пройти його при наступному збереженні, а це збереження може прийти звідки ви не чекали: нічна інтеграція, пакетна зміна власника, зведення, масове оновлення зі списку (list view). Що з цього на нього натрапить, і що станеться з тим завданням, коли один запис не пройде? У розділі Перш ніж вмикати — послідовність, яку я використовую.

Не переписуйте історію, щоб догодити правилу

А що з двадцятьма тисячами старих записів? Якщо дані хибні й ви знаєте правильні значення, виправте їх. Але я бачив інший вид «виправлення»: ніхто не знає історичної правди, записам просто треба пройти перевірку, тож їх оновлюють значеннями, що задовольняють сьогоднішнє правило. Мені це не подобається. Оновлення старих записів заради відповідності змінює LastModifiedDate і знищує ключову історичну інформацію, а вигадування значень означає вдавати, що ми знаємо про минуле те, чого не знаємо. Дайте правилу обхід для записів, старших за нього, а не переписуйте історію. Це може бути некрасиво, але чесно.

Перевірка в інтерфейсі — не перевірка даних

Зробіть поле обов’язковим у макеті сторінки — і користувачі не зможуть зберегти без нього. Потім нічна інтеграція вставляє 50 000 записів. Чи використала вона вашу сторінку? Ні. Як і масове завантаження, клієнт API чи агент. Вимога в інтерфейсі захищає цей екран, а не дані. Перевірку полів у dynamic forms можна обійти так само. Тож питайте: через що ці дані можуть потрапити? Lightning, портал, мобільний застосунок, інтеграція, API, масове завантаження, Flow, Apex, агент. Що більше дверей, то менше я довіряю правилу, яке охороняє лише одні з них.

Щабель четвертий: правила дублікатів

Тепер ми переходимо від узгодженості всередині запису до узгодженості між записами. Acme Corporation, ACME Corp, Acme Inc.: чотири клієнти чи один? Жодне правило поля не дасть на це відповіді. Правила зіставлення визначають, як порівнюються записи; правила дублікатів вирішують, що відбувається, коли знайдено ймовірний дублікат: дозволити з попередженням, заблокувати чи повідомити. На об’єкт можна мати до п’яти активних правил дублікатів і до трьох правил зіставлення в кожному, а ключі зіставлення звужують кожне порівняння до 100 найімовірніших дублікатів (Things to Know About Duplicate Rules (opens in a new tab)).

Їхня ціна — тертя. Якщо кожен акаунт, який створює менеджер, показує Possible duplicate found, іноді це саме те, що вам потрібно, а іноді люди вчаться клацати далі, не читаючи. Легітимні записи можуть бути схожими, а інтеграції може знадобитися інша поведінка, ніж людині. До того ж попередження — власне попередження Salesforce: його сповіщення і список можливих дублікатів можуть не вписатися в користувацький екран, який ви збудували, а коли збереження headless (без інтерфейсу) — інтеграція, завантаження даних, агент, — екрана, щоб його показати, немає взагалі. Тож вирішіть, як дублікат проявляється на кожному шляху: попередження для людини, заблоковане збереження і помилка для API або опція Report і набори дублікатів (duplicate record sets), щоб хтось переглянув пізніше. Хороша архітектура — це не максимальний контроль, а правильний контроль.

І перевірте, які двері правило дублікатів справді охороняє (Things to Know About Duplicate Rules (opens in a new tab)). Через API та інструменти імпорту даних попередження ніхто не бачить: правило, налаштоване на сповіщення, просто блокує збереження. Деякі шляхи повністю оминають правила: Quick Create, кнопка Undelete, ручне злиття, записи, додані Lightning Sync чи Einstein Activity Capture. А записи, збережені в ту саму мить, не порівнюються між собою, лише із записами, які вже є в Salesforce. Завантажте файл, де той самий клієнт трапляється двічі, — і обидва рядки можуть пройти. Правило дублікатів — добра сітка. Але не замок на дверях.

Варто знати для іспиту. Правила дублікатів не порівнюють між собою записи, збережені в ту саму мить, лише із записами, які вже є в Salesforce. Через API та інструменти імпорту сповіщення немає: дублікат, який упіймало правило, просто не зберігається. А збереження і все, що воно запускає, виконуються як одна транзакція: якщо будь-яка частина не вдається, відкочується все.

Одна межа. Правила дублікатів тримають у чистоті одну org. Вони не розв’язують корпоративної ідентичності. Якщо в Salesforce є Acme Corporation, в ERP — ACME-10382, а в білінгу — клієнт 77193, правило дублікатів не скаже вам, що це та сама компанія. Це основні дані, розділ 6.

Щабель п’ятий: автоматизація

Деякі правила надто складні для нижчих щаблів: їм потрібні пов’язані записи, інша система, залежні записи, багатокроковий процес. Це Flow, Apex, іноді логіка інтеграції. (Не Workflow Rules і не Process Builder — їх більше не підтримують.) Автоматизація потужна і дорожча: більше рухомих частин, більше тестування, більше обробки помилок, більше способів, у які одна автоматизація спіткнеться об іншу. А код приносить власні помилки. Якщо це може забезпечити тип поля, я не пишу Apex. Якщо правило перевірки чітко це виражає, я не будую flow лише тому, що Flow є. Не розв’язуйте проблему поля двигуном процесів.

Усе або нічого: коли записи змінюються разом

Досі кожен щабель захищав одне збереження. Але записи змінюються разом: доставка та її позиції, замовлення та його рядки, flow, що оновлює три об’єкти. Тут платформа дає вам сильну гарантію. Збереження і все, що воно запускає, — тригери, flows, класи, які вони викликають, — виконуються як одна транзакція: якщо будь-яка частина не вдається, усе відкочується і нічого не фіксується (Apex Transactions (opens in a new tab)). Пів доставки ви не отримаєте.

Масова робота — виняток, який ви обираєте самі. Завантаження даних чи метод Apex Database можуть дозволити частковий успіх: добрі записи зберігаються, погані повертаються зі своїми помилками, і хтось мусить ними зайнятися (DML Statements vs. Database Class Methods (opens in a new tab)). Для завантаження мільйона рядків це часто правильно, але тоді узгодженість — це процес: хто читає файл помилок і що стається із записами, які не пройшли?

А ще є таймінг. Два збереження в ту саму мить можуть обидва пройти перевірку, яку кожне окремо не пройшло б. Flow, який шукає наявне замовлення, а потім створює його, може пропустити два, а ми щойно бачили, що правила дублікатів не порівнюють записи, збережені одночасно. Поле, позначене Unique, або External ID платформа перевіряє при кожному збереженні, тож виграє лише одне з них. Це ще одна причина опускати унікальність до рівня поля. Блокування, конкуренція й повтори — окрема тема; розділ 11, Транзакції, паралельність і надійність, розглядає її глибоко.

Опускайте правило вниз, доки йому там місце

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

Кожен рівень має свою ціну

Click to enlarge

Ось компроміс, який я хочу, щоб ви побачили. Типи полів і контрольовані значення прості й сильні, але лише для того, що може виразити поле. Required і Unique — грубі інструменти: увімкнувши їх, кожен запис даних мусить їх задовольняти. Правила перевірки виражають багатші умови, але можуть блокувати редагування старих записів і заскочити розгортання. Правила дублікатів захищають між записами, але додають тертя для користувачів та інтеграцій. Автоматизація впорається з чим завгодно, але змушує вас володіти оркестрацією, помилками, тестами й продуктивністю. Безкоштовного рівня немає. Обирайте рівень для кожного правила, знаючи, як він ламається.

Перш ніж вмикати

Додати правило в наявну org — це впровадження, а не прапорець. Скільки записів порушують його сьогодні і чому? Чи вони справді хибні? Чи можемо ми знати правильне значення? Чи правило правдиве історично, чи лише відтепер? Які інтеграції, тести й автоматизації на нього натраплять? Хороша послідовність: виміряти, виправити те, що ви можете довести як хибне, обмежити правило, додати свідомий обхід для легітимної історії, протестувати кожен шлях запису, а тоді вмикати. Вимірювання й очищення — окремі дисципліни: профілювання, стандартизація, моніторинг, стюардство даних, — і їх розглядає розділ 5, Якість даних і врядування. Набагато краще, ніж поставити прапорець у п’ятницю й виявити наслідки в суботу ввечері.

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

Steve Trucking: захистіть доставку

Візьміть доставку. Її статус береться з одного словника: список вибору, обмежений. Номер замовлення роздрібного партнера має бути унікальним у межах партнера, тож це External ID, позначений як унікальний і використаний для upsert маніфесту. Фактичний час доставки обов’язковий, щойно статус стає Delivered: правило перевірки, обмежене цією зміною. Зупинку з монтажем не можна закрити, доки її чекліст не заповнено й потрібні фото не зроблено (для посудомийної машини — лінія води, злив і рівень): правило перевірки або автоматизація, якщо треба перевіряти фото, що зберігаються поза платформою. Те саме замовлення, що прийшло двічі з повторно надісланого маніфесту, ловить External ID; два різні замовлення, що схожі між собою, — це питання зіставлення.

Зауважте: я не сказав «покладіть усе у flow». Кожне правило стоїть на власному щаблі. Для кожного правила питайте: який найнижчий рівень забезпечує його правильно для кожного шляху запису, що має значення?

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

• На якому щаблі місце кожному правилу: тип поля, контрольований словник, required чи unique, правило перевірки, правило дублікатів чи автоматизація.
• Які шляхи запису треба захистити: інтерфейс, портал, мобільний застосунок, інтеграції, масові завантаження, API, автоматизацію й агентів.
• Чи застосовується нове правило до історичних записів, чи обмежене новими й зміненими даними з обходом для минулого.
• Чи можна виправити наявні погані дані на основі доказів, а не переписати їх, щоб вони пройшли перевірку.
• Скільки тертя, складності й підтримки варте правило.

Чисті дані не беруться з прохань до людей вводити хороші дані. Вони беруться з архітектури, яка робить правильне легким, хибне важким, а важливі правила — важкими для обходу. Далі ми зберемо розділ докупи на фрагменті Steve Trucking.

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

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) і Roll-Up Summary Field (opens in a new tab) (англійською, перевірено 2026-10-13).
• Salesforce Help, Picklist Limitations (opens in a new tab) (англійською, перевірено 2026-10-02).
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (англійською, перевірено 2026-10-02).
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (англійською, перевірено 2026-10-13): ліміти, шляхи, на яких правила не працюють, збереження через API та імпорт, заблоковані без сповіщення, одночасні збереження не порівнюються.
• Apex Developer Guide, Apex Transactions (opens in a new tab) і DML Statements vs. Database Class Methods (opens in a new tab) (англійською, перевірено 2026-10-13): одна транзакція відкочується як ціле; методи Database можуть дозволяти частковий успіх.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (англійською, перевірено 2026-10-02).