Поля — це теж архітектура

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

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

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

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

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

Створення поля займає приблизно хвилину. New Field, оберіть тип, назвіть, Next, Next, Save. Саме тому поля не сприймають як архітектуру.

Зайдіть в org, якій десять років, і відкрийте Account. П’ятсот полів. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Три різні номери клієнта. Прапорець, який ніхто не видалить, бо ніхто не знає, яка інтеграція ним досі користується. Створення поля зайняло хвилину. Жити з ним — роки. Тож ідея цього модуля проста: поле — це архітектурне рішення. Не завжди велике, але кожне поле кодує щось про зміст, поведінку, ідентичність чи якість даних, і, як і об’єкти, поля легко додавати й напрочуд важко прибирати.

Що ці дані насправді означають?

У розділі 2 ми дали сутностям атрибути: Доставка має заплановане вікно, Вантажівка — VIN. Тепер ми їх реалізуємо, і тут люди одразу стрибають до «текстового поля». Зачекайте. Перш ніж тип, я хочу знати, що дані означають. Це число чи ідентифікатор, у якому просто є цифри? Дата чи момент часу? Вільний текст чи одне зі схвалених значень? Його вводить людина чи ним володіє інша система? Чи може воно змінюватися? Чи має бути унікальним? Чи може бути відсутнім? Чи варто його взагалі зберігати, чи обчислювати? Це не запитання Setup. Це запитання архітектури даних, і тип поля йде після відповідей на них.

Число — не завжди число

Steve Trucking дає кожній вантажівці бортовий номер, скажімо 001247. Числове поле? Мабуть, ні. Чи ми додаємо бортові номери? Вантажівка 1247 мінус вантажівка 1246 — це одна вантажівка? Це ідентифікатор, у якому просто є цифри, а поле Number ще й відкине провідні нулі. Те саме з поштовими індексами, кодами продуктів, номерами рахунків і номерами відстеження. Те, як виглядає значення, не каже, що воно означає. Обирайте тип за потрібною поведінкою, а не за тим, як виглядають зразкові дані.

Чи має людина її впізнавати?

Кожен користувацький об’єкт отримує поле Name, і перше рішення — текст чи автонумерація. Я питаю: чи має людина впізнавати цю річ? Люди знають роздрібного партнера за назвою, а вантажівку — за бортовим номером. А маніфест, який система генерує щоночі? Ніхто не повинен вводити «Маніфест 10-02 номер 3», бо Salesforce вимагав Name. Дайте йому автонумерацію. Тільки не плутайте цей згенерований Name з ідентичністю запису: автонумерація допомагає користувачам, ID Salesforce ідентифікує запис, а власне посилання роздрібного партнера на маніфест може ідентифікувати ту саму річ між системами. Три різні роботи.

Екран деталей

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

New Custom Field, крок 2: деталі (скриншот, 2026-10-12). Повний розмір

Два поля схожі, але виконують різну роботу. Description (опис) — для людей, які підтримують org, а тепер і для інструментів ШІ, що її читають: що поле означає, хто ним володіє, звідки воно береться. Help Text (текст довідки) — для користувача на екрані: що тут вводити. Заповнюйте обидва. Далі йдуть Required, Unique і External ID, і кожне з них заслуговує окремого розділу. Під ними Default Value (значення за замовчуванням) може бути формулою, тож новий запис може починатися з розумного значення, а не з порожнечі.

Обов’язковість — більше рішення, ніж здається

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

«Обов’язкове» звучить як рішення про якість даних, і іноді так і є. Але коли значення стає відомим — частина бізнес-процесу. Тож не ставте Required лише тому, що хтось каже «ми завжди цього хочемо». Запитайте, коли воно відоме, хто його надає і що станеться, коли його немає. Ми поставимо це на повну драбину узгодженості в модулі 7.

Унікальність теж щось означає

Позначаючи поле унікальним, я роблю твердження про бізнес: не «зазвичай не повторюється», а «два записи ніколи не можуть мати цього значення». Це сильне твердження. А екран змушує вирішити ще одне: «ABC» і «abc» — це те саме значення чи різні? Нечутливість до регістру — безпечніший вибір за замовчуванням для всього, що вводить людина. Тут діє правило ключів із розділу 2: унікальний, незмінний, без змісту, ніколи не персональні дані. Якщо мені кажуть, що робоча пошта співробітника унікальна, я починаю питати: чи може вона змінитися, чи може людина піти й повернутися, чи можуть адреси використовуватися повторно, що станеться після поглинання? Пошта може бути корисною, навіть унікальною сьогодні. Це не робить її добрим ідентифікатором.

External ID: ідентичність через межу

Тут External ID відпрацьовують свій хліб. Екран добре це описує: поле стає «унікальним ідентифікатором запису із зовнішньої системи». В ERP є клієнт 873492; у Salesforce — власний ID запису. Коли ERP надсилає оновлення, як знати, до якого запису воно належить? Позначте поле як External ID, і інтеграція зможе робити за ним upsert: створити запис, якщо його немає, оновити, якщо є (Upsert a Record Using an External ID (opens in a new tab)). А завантажуючи дочірні записи, можна вказати батька за його External ID, замість спершу запитувати ID Salesforce. Я люблю казати: ви дозволяєте Salesforce зробити пошук за вас. Дуже потужно.

Зверніть увагу: номер ERP не стає ідентичністю запису Salesforce. Це атрибут, і запис може нести кілька: ID клієнта в ERP, застарілий ID, ID партнера. Це нормально. Одну бізнес-сутність різні системи можуть знати по-різному. Архітектурне запитання — яка система володіє кожним ідентифікатором і що вона обіцяє: позначайте його унікальним, лише якщо бізнес справді це гарантує.

Тип поля за типом поля

Тепер самі типи. Відкрийте New Field на будь-якому об’єкті, і Setup покаже весь список, згрупований так, як я його пройду: поля, які Salesforce обчислює за вас, поля зв’язків, а потім типи даних.

Setup, New Custom Field, крок 1: типи даних (скриншот, 2026-10-12). Повний розмір

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

Група	Тип	Запам’ятайте
Обчислювані	Auto Number	До 30 символів, із них 20 — префікс або суфікс; мітка для людей, а не ідентифікатор запису
	Formula	Обчислюється під час читання, не зберігається; 3 900 символів
	Roll-Up Summary	Кількість, сума, мінімум чи максимум дочірніх записів; лише master-detail
Зв’язки	Lookup, Master-Detail, External Lookup	Модуль 7
Дані	Checkbox	Істина чи хиба, зі значенням за замовчуванням, яке обираєте ви; у flow все одно може з’явитися null
	Number, Percent, Currency	Правила округлення; початкові нулі відкидаються; 15 знаків після коми
	Date, Date/Time, Time	День, момент чи час доби; моменти зберігаються в UTC
	Email, Phone, URL	Форматуються й перевіряються під час збереження: 80, 40 і 255 символів
	Geolocation, Address	Складені поля, що коштують більше за одне поле: 3 і 9
	Picklist, Multi-Select	Керований словник, яким володіє адміністратор
	Text, Text Area, Long, Rich, Encrypted	До 255 — у записі й можуть індексуватися; понад це — без індексу і фільтрації

Поля, які обчислює Salesforce

Auto Number (автонумерація) присвоює кожному новому запису наступний номер у послідовності, у форматі, який ви визначаєте, як-от T-{000000}. Використовуйте його, коли людині потрібна зручна позначка і ніхто не повинен її вигадувати. Усе значення — до 30 символів, і 20 із них зарезервовано для префікса чи суфікса. Просто пам’ятайте з розділу 2: це мітка для людей, а не ідентифікатор запису, і номери не завжди йдуть строго послідовно.

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

New Custom Field, формула: вибір типу значення, що повертається (скриншот, 2026-10-12). Повний розмір

Потім ви пишете саму формулу — з полями, операторами й функціями — і перевіряєте її синтаксис. Зверніть увагу на кнопку Use Formula Assistant: тепер ШІ Salesforce допоможе вам написати формулу. Користуйтеся ним, а потім прочитайте, що він написав. Формулою володієте ви, а не асистент.

Редактор формул з Formula Assistant (скриншот, 2026-10-12). Повний розмір Формула може мати до 3 900 символів і не може перевищувати 15 000 байтів після збереження чи компіляції; довгу формулу можна розбити на кілька полів-формул, що посилаються одне на одне. Довгі текстові області, зашифровані поля і поля Description у них використовувати не можна.

Поля Roll-Up Summary (зведені поля) стоять на головному записі й рахують кількість, суму, мінімум чи максимум його дочірніх записів. Вони працюють лише через зв’язок master-detail, і це одна з найбільших причин узагалі обирати master-detail. Ми повернемося до них і до їхніх лімітів у модулі 7.

Зберігати чи обчислювати?

Чи треба нам узагалі зберігати це значення? Якщо в мене є кількість і ціна за одиницю, чи має хтось або якась автоматизація підтримувати загальну суму? Можливо, її має обчислювати формула: одне джерело розрахунку, перераховується під час читання, тож змініть кількість — і відповідь піде слідом. Формули мають власні ліміти (розмір при збереженні та довжина відображення; Formula Field Limits and Restrictions (opens in a new tab)), а складні формули важко підтримувати.

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

Поля зв’язків

Зв’язки Lookup, Master-Detail і External Lookup — теж поля, і саме в них лінії вашої моделі стають реальними. Lookup — вільне посилання; master-detail прив’язує життя, власність і безпеку дочірнього запису до батька; external lookup дотягується до зовнішнього об’єкта з модуля 4, зіставляючи за його External ID. Вибір між ними — достатньо велике рішення, щоб отримати власний модуль.

Checkbox

Checkbox (прапорець) — найпростіше поле з усіх: істина чи хиба, позначено чи ні. Він ідеальний для факту «так/ні» про запис: Is Active, Install Required, Signed For. Коли ви його створюєте, Salesforce змушує обрати значення за замовчуванням — позначено чи ні, — і це справжнє рішення: з нього починається кожен новий запис, зокрема записи, які інтеграція створює, не надсилаючи це поле. Звіти й подання списків фільтрують його як True і False; інструменти імпорту і щотижневий експорт показують його як 1 і 0.

Одна пастка, яку варто знати. Поле в записі має два значення, але автоматизація навколо нього може мати третє. У flow змінна-прапорець, якій ніколи не присвоїли значення, — це null, а не false, і збереження її в запис завершується помилкою (Trailblazer Community (opens in a new tab); див. також відому проблему Salesforce W-11208535 (opens in a new tab)). Оберіть розумне значення за замовчуванням і навмисно обробляйте null у своїх flow і коді.

Number, Percent і Currency

Number зберігає дійсне число і відкидає початкові нулі — саме тому бортовий номер на кшталт 001247 не є Number. Salesforce округлює числові поля від нуля на половині (half away from zero): 12,345 стає 12,35, а −12,345 стає −12,35. А в полях злиття (merge fields) округлення йде за локаллю користувача, а не за кількістю знаків після коми, заданою в полі.

Percent зберігає десятковий дріб і показує відсоток: введіть 0,10 — і побачите 10%. Після 15 знаків після коми значення втрачають точність.

Currency форматується як гроші, а в org із кількома валютами несе код валюти і може використовувати обмінні курси; з розширеним керуванням валютами (opens in a new tab) (advanced currency management) можливості можуть використовувати датовані курси — курс за період, у якому закрилася угода. Датовані курси використовують лише можливості та все навколо них (продукти, графіки, розподіли і їхні звіти); поля валюти на інших об’єктах тримаються єдиного статичного курсу. Стежте за округленням: без знаків після коми Salesforce просто відкидає дробову частину (23,5 стає 23); з одним чи більше знаками — округлює від нуля на половині.

Date, Date/Time і Time

Три типи — три різні значення. Date — це день: контракт спливає в певну дату. Date/Time — це момент: доставка прибула о 9:42 того ранку. Time — це час доби взагалі без дати: магазин відкривається о 07:00 щодня.

Пастка — у моменті. Salesforce зберігає значення дати/часу в GMT (UTC). Час, який вводить користувач, читається в його часовому поясі, конвертується і зберігається; коли хтось його читає, він знову конвертується в часовий пояс того, хто читає. Здебільшого це саме те, що вам треба. Але ось приклад, який я наводжу на заняттях: координатор у Лос-Анджелесі пізно ввечері в неділю, о 22:00 за тихоокеанським часом, реєструє доставку. Під капотом Salesforce зберіг ранок понеділка, 05:00 за GMT. Звіт, згрупований за днями в іншому часовому поясі, чи інтеграція, що читає сире значення, може віднести ту недільну доставку на понеділок. «День, коли це сталося» залежить від того, чий годинник ви питаєте. Стежте за часовими поясами користувачів і вирішіть, який із них має на увазі бізнес.

І будьте обережні, порівнюючи їх. Під капотом дата/час — це одне велике число: Apex читає його як кількість мілісекунд від 1 січня 1970 р., 00:00:00 GMT (Datetime Class (opens in a new tab)). Це точний момент, а не день. Тож перевірка, чи дві дати/часи рівні (==), майже ніколи не робить того, що вам треба: 9:42:00 і 9:42:01 не рівні, як і «понеділок» та будь-який момент у понеділок. Натомість питайте про діапазон: не раніше початку (>=) і не пізніше кінця (<=). «Усі доставки в понеділок» — це всі доставки >= понеділок 00:00 і <= понеділок 23:59:59, у тому часовому поясі, який, як ви вирішили, має на увазі бізнес.

І ще цікавинка: Salesforce не може зберегти будь-яку дату. Допустимі дати — від 1 січня 1700 р. до 31 грудня 4000 р., і Salesforce дає той самий діапазон для дат і дат/часу (Data Import Dates (opens in a new tab)). Навіть межі — це моменти в GMT, тож для користувача за тихоокеанським часом найраніше допустиме значення — 16:00 31 грудня 1699 р. Дата заснування вашого історичного товариства може туди не вміститися. А класичний трюк «без дати завершення», 31 грудня 9999 р., буде відхилено; якщо вам потрібен заповнювач у далекому майбутньому, він має бути в 4000 році чи раніше.

Email, Phone і URL

Це форматовані поля, і вони роблять більше, ніж просто зберігають символи. Email містить до 80 символів і перевіряється на правильний формат; у контактах і лідах клік по ньому починає лист на цю адресу. Phone містить до 40 символів, форматується як номер телефону і стає click-to-dial (дзвінок одним кліком), коли до org підключено телефонну систему. URL містить до 255 символів і відкривається як посилання. Це платформа дає вам поведінку безкоштовно, і саме тому я ніколи не зберігав би номер телефону у звичайному текстовому полі.

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

Geolocation і Address

Geolocation містить широту й довготу. Під капотом поле Location__c — це насправді два значення, які можна читати й задавати окремо: Location__Latitude__s і Location__Longitude__s. І за ним можна робити запити: функції SOQL DISTANCE і GEOLOCATION знаходять записи в межах радіуса або сортують їх за відстанню. «Усі відкриті доставки в межах 25 миль від цієї вантажівки» — це один запит: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Address містить цілу адресу — вулицю, місто, штат чи провінцію, поштовий індекс і країну, — і користувачі можуть шукати адресу, а її частини заповняться самі.

Обидва — складені поля (compound fields): одне поле на екрані, кілька під капотом. І вони коштують більше за одне поле в ліміті вашого об’єкта: Geolocation рахується як три користувацькі поля, а Address — як дев’ять. На об’єкті, який уже переповнений, це важливо.

Picklist і Multi-Select

Список вибору (picklist) контролює, що можуть вводити користувачі: одне значення зі списку, який ви визначаєте. Статус? Мабуть, список вибору. Але значення — це метадані, і додавати чи змінювати їх має адміністратор. Тож я все одно питаю, хто володіє значеннями, як часто вони змінюються, чи потрібен той самий список кільком об’єктам, чи несуть значення власну інформацію і чи не володіє словником інша система.

Де живуть значення — теж рішення. Коли список використовується один раз, на одному полі, тримайте значення в самому полі, на об’єкті; саме так Salesforce робить за замовчуванням. Але коли той самий набір значень починає з’являтися в кількох місцях — Регіон на акаунті, на доставці і на складі, — перетворіть його на глобальний набір значень, перш ніж копії розійдуться. Глобальний набір значень тримає один список для всіх, до 1 000 значень, активних і неактивних разом (Picklist Limitations (opens in a new tab)). Власний опис у Setup пояснює, чому це важливо: набір значень «обмежений, тож користувачі не можуть додавати несхвалені значення через API». Один список, один власник, і жодна інтеграція не протягне нове написання.

Останній пункт — це різниця між обмеженим (restricted) і необмеженим (unrestricted) списком. В обмеженому списку вибору дозволені лише значення, які визначив адміністратор, звідки б вони не прийшли: користувач, імпорт чи інтеграція, що надсилає щось інше, отримує помилку «bad value for restricted picklist field» (неприпустиме значення для обмеженого списку вибору), і запис не зберігається. У необмеженому списку вибору користувачі все одно обирають зі списку на екрані, але API, імпорти й автоматизація можуть надіслати будь-яке значення, і Salesforce збереже його і додасть як неактивне значення (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab)). Ось так org і отримує «Delivered», «delivered» і «Dlvrd». Глобальні набори значень завжди обмежені. Мій вибір за замовчуванням — обмежений; необмежений — свідомий вибір для випадків, коли значеннями справді володіє інша система, і тоді хтось відповідає за прибирання неактивних.

Setup, Picklist Value Sets: новий глобальний набір значень (скриншот, 2026-10-12). Повний розмір

Список множинного вибору (multi-select picklist) дає користувачу обрати кілька значень, що зберігаються разом через крапку з комою. Зручно на екрані, незграбно всюди інде: складніше фільтрувати, звітувати й інтегрувати, і його не можна використати у фільтрі зведеного поля. Кілька значень для одного запису зазвичай означає урок розділу 2: там є дочірній об’єкт, який хоче вийти назовні.

Список вибору також має на одне значення більше, ніж ви визначили: порожнє. Запис може стояти без вибраного значення, і на цьому люди спотикаються. У формулі чи правилі перевірки не можна перевірити список вибору самим ISBLANK; ви пишете ISBLANK(TEXT(Field__c)) або ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). Тож вирішіть, що означає «немає значення» для кожного списку вибору: чи це дозволено і що це означає, коли трапляється? А потім навчіть свої формули, правила перевірки й фільтри це обробляти.

А іноді атрибут насправді є сутністю. Хтось просить список вибору розподільчих центрів. Їх дев’ять. Легко. Потім ми дізнаємося, що в кожного є адреса, менеджер, години роботи, місткість, регіон і вантажівки. Це не список вибору; це річ. Не перетворюйте сутність на список вибору лише тому, що їх поки небагато. У перший рік це чудово, а на п’ятий — жахливо. (У модулі 5 розділу 2 є мої емпіричні правила, коли список заслуговує на власний об’єкт.)

Сімейство текстових полів

Я викладаю текст як два види, і межа між ними — 255 символів.

До 255: зберігається разом із записом. Text містить до 255 символів, і його можна використовувати майже всюди: у формулах, фільтрах, звітах, поданнях списків, як унікальне поле чи External ID, і його можна індексувати. Text Area теж містить 255, в окремих рядках, як коротка нотатка.

Понад 255: зберігається за посиланням. Text Area (Long) містить до 131 072 символів, а Text Area (Rich) — стільки ж із форматуванням, посиланнями й зображеннями. Я думаю про них як про збережені збоку, а запис тримає вказівник, і поводяться вони саме так: без індексу, тож їх не можна зробити унікальними чи External ID; за ними не можна фільтрувати в реченні SOQL WHERE (SOQL WHERE (opens in a new tab)); формули не можуть їх використовувати (Formula Field Limits and Restrictions (opens in a new tab)); а звіти показують лише перші 254 символи користувацького поля, і фільтри звітів шукають лише приблизно в перших 255 (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Зображення, завантажені в поле форматованого тексту, можуть бути до 1 МБ кожне, і вони рахуються у сховищі файлів, а текст — у сховищі даних (Rich Text Area Field Considerations (opens in a new tab)). Тож якщо комусь треба шукати, сортувати, зіставляти чи звітувати за значенням, тримайте його в межах 255 і залишайте полем Text.

Text (Encrypted) зберігає до 175 символів у зашифрованому вигляді, використовуючи Classic Encryption. Якщо ваша org використовує Shield Platform Encryption, ви натомість шифруєте звичайне поле Text, і так само можна шифрувати й багато інших типів.

Дайте кожному полю опис

Мій стандарт: кожне поле отримує опис. Я давно в це вірю, а в епоху ШІ це важить як ніколи: кожен інструмент ШІ й агент, що читає вашу org, читає описи, щоб зрозуміти, що означає поле. Порожній опис — це здогадка, що чекає свого часу. Що означає Customer_Status__c? Хто ним володіє? Звідки воно береться? Чи можуть користувачі його редагувати, чи ERP перезапише його сьогодні вночі? За пів року я не пам’ятатиму, а за три роки адміністратор, що підтримує org, не знатиме, якщо ми йому не сказали. Мітка — не документація, і ім’я API теж.

На інтенсивно спільних об’єктах (Account, Contact, Opportunity) я також використовую префікси в назвах для спеціальних полів, щоб їхнє походження й призначення було видно в самій назві: наприклад, усе, чим володіє ERP, починається з того самого префікса. Мені не потрібні API-імена з дванадцяти слів. Я хочу, щоб модель пояснювала себе сама.

Класифікуйте важливе: поля таксономії

Salesforce дає кожному полю набір метаданих класифікації. Я називаю їх полями таксономії. Можна записати власника даних; використання поля (Active, DeprecateCandidate, Hidden); рівень чутливості даних (Public, Internal, Confidential, Restricted, MissionCritical); і категорію відповідності: PII, HIPAA, GDPR, PCI, CCPA та інші. Вони працюють і на стандартних полях, і на користувацьких (Data Classification Metadata Fields (opens in a new tab)).

Навіщо? Бо їх можуть читати процеси. Позначте поле як GDPR, і процес зможе знайти всі GDPR-поля запису та замаскувати чи прибрати їх. А коли довірчий шар Salesforce надсилає промпт великій мовній моделі, він може використати саме цю класифікацію, щоб замаскувати чутливі поля: на виході він замінює ім’я клієнта, скажімо «Maria Lopez», заповнювачем, модель ніколи не бачить імені, а на вході ім’я повертається у відповідь (Einstein Trust Layer (opens in a new tab)).

Оновлення. Salesforce тепер документує, що маскування за шаблонами й за полями для LLM вимкнене для агентів: маскування може прибрати контекст, потрібний агентові для відповіді (Data Masking Limitations in Agentforce (opens in a new tab)). Класифікація досі керує маскуванням для інших функцій генеративного ШІ, але не розраховуйте на неї, щоб тримати персональні дані подалі від агента; це рішення про доступ і дизайн (розділ 12).

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

За межами іспиту: що змінює ШІ. Погана документація полів раніше карала наступного адміністратора. Тепер вона вводить в оману кожен ШІ-інструмент і агента, що читає схему: Flag2__c чутливе, авторитетне, досі використовується? ШІ також створює поля швидше за будь-яку команду, тож назви, описи й класифікація — частина архітектури, а не прибирання.

Кожне поле — це зобов’язання

Щойно поле почало збирати дані, на нього починає спиратися все. Екрани його показують, flow розгалужуються за ним, правила перевірки його перевіряють, звіти групують за ним, інтеграції його надсилають і читають, а тепер ще й інструменти ШІ міркують про нього. Кожен із них робить припущення про поле: його тип, довжину, чи буває воно порожнім і що означають його значення. Змініть поле пізніше — і вам доведеться спершу знайти кожне з цих припущень. Перейменувати значення списку вибору, скоротити текстове поле чи перетворити поле Text на список вибору — звучить як дрібна зміна, а може зламати інтеграцію в системі іншої компанії. Ось чому поле — це зобов’язання.

Click to enlarge

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

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

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

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

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (англійською, перевірено 2026-10-02).
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) і Data Masking Limitations in Agentforce (opens in a new tab) (англійською, перевірено 2026-10-02).
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (англійською, перевірено 2026-10-02).
• Salesforce Help, Picklist Limitations (opens in a new tab) (англійською, перевірено 2026-10-02).
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab) (англійською, перевірено 2026-10-02).
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (англійською, перевірено 2026-10-02).