Спроєктуйте фізичну модель Salesforce

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

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

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

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

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

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

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

Почніть із того, що ми вже знаємо

Розділ 2 виконав концептуальну роботу: роздрібний партнер, отримувач, маніфест, доставка, позиція доставки, вид зупинки, бригада, вантажівка, розподільчий центр, фото. Ми назвали зв’язки й спитали, що вони означають. Я не повторюватиму цього. Питання тепер — як ці концепції живуть у Salesforce. Один факт із брифу важливий одразу: Steve Trucking уже використовує Field Service для записів на візити, бригад і мобільного застосунку.

Роздрібний партнер: не вигадуйте Account

Роздрібний партнер — компанія, на яку працює Steve Trucking. У Salesforce уже є об’єкт, призначений для компаній: Account. Чиста відповідність. Тож ніякого Retail_Partner__c лише тому, що бізнес каже «партнер». Це Account з типом запису Retail Partner, щоб відрізняти його від інших організацій, а разом із ним ідуть контракти, звернення, контакти для керівників DC і доступ до порталу для цих контактів. Легке рішення. Не всі такі.

Номер замовлення партнера — не наша ідентичність

Кожен роздрібний партнер надсилає власні номери. Замовлення одного партнера виглядає як 8843119, іншого — як A-984732. Ці номери важливі, але чиї вони? Партнера. У Salesforce є власний ID запису, а в партнера — номер, яким він користується, коли спілкується з нами. Можуть існувати обидва; це «одна річ, кілька ідентифікаторів» із розділу 2.

Тож номер партнера стає External ID, за яким інтеграція зіставляє оновлення. А оскільки два партнери можуть використовувати той самий номер, ідентичність — це партнер плюс номер, а не сам номер. Не робіть номер партнера універсальною ідентичністю доставки лише тому, що він прийшов першим, і не змушуйте інтеграцію щоразу шукати в текстовому полі, коли їй треба знайти запис.

Доставка: дивіться на материнський корабель

Ось де виникає спокуса створити Delivery__c. Бізнес сказав «доставка», отже, нам потрібен об’єкт Delivery. Саме цього я не хочу, щоб ви робили першим. Дивіться на материнський корабель, як ми робили в модулі 2. Що вже є в Salesforce для роботи, яка виконується на місці, з життєвим циклом, позиціями, плануванням і бригадою в полі? Work Order (робоче замовлення) із Field Service: Salesforce описує його як польову сервісну роботу, яку треба виконати для клієнта (WorkOrder (opens in a new tab)). Запланований візит із часовим вікном — це Service Appointment (сервісний візит), і саме його планує диспетчерська та показує застосунок бригади.

Отже, доставка → Work Order. Не тому, що слова збігаються, — вони не збігаються. А тому, що поведінка відповідає можливостям платформи, за які ми вже платимо й якими збираємося користуватися. Стандартний об’єкт не мусить говорити мовою бізнесу. Він мусить правильно представляти концепцію.

Click to enlarge

Крок 1 з 4: материнський корабель. Кожна картка — бізнес-концепція, під нею — її об’єкт Salesforce.

Але стандартні об’єкти приходять із багажем

Друга половина: Work Order не безкоштовний. Він приносить ліцензування Field Service, власні зв’язки, поведінку безпеки, обов’язкові поля, автоматизацію й життєвий цикл, а інші частини платформи очікують від нього певної поведінки. Ми обираємо його, бо відповідність чиста, і ми користуємося тим, що побудовано навколо нього. Якби Steve Trucking не хотів нічого з Field Service, а модель на кожному кроці воювала з процесом, я б переглянув рішення. Архітектура — це відповідність, а не назва.

Позиції доставки: ідіть за моделлю

Щойно доставка стала Work Order, подивіться на решту цієї моделі, перш ніж щось вигадувати. Work Order Line Item (рядок робочого замовлення) — це підзавдання робочого замовлення (WorkOrderLineItem (opens in a new tab)): холодильник, монтаж, вивезення старого. Отже, позиція доставки → Work Order Line Item. Зауважте, що перше рішення сформувало друге. Ми не обираємо об’єкт для кожної сутності окремо. Приймаєте модель — розберіться з рештою, перш ніж будувати навколо неї користувацькі структури.

Що це за зупинка?

У Steve Trucking зупинка — це лише доставка, доставка з монтажем або доставка з вивезенням старого, і кожен вид має власну тривалість, навички бригади й чекліст монтажу. У розділі 2 ми вирішили, що це сутність, а не мітка. У Field Service така вже є: Work Type (тип робіт), шаблон для типу роботи, який можна застосувати до робочих замовлень і рядків (WorkType (opens in a new tab)). Отже, вид зупинки → Work Type. Знову ж таки, не тому, що існує щось під назвою Work Type, а тому, що концепція й поведінка збігаються.

Click to enlarge

Крок 2 з 4: ідіть за моделлю. Рядки й Work Type приходять разом із Work Order.

Маніфест: тепер я хочу користувацький об’єкт

Чи є стандартний об’єкт для «списку партнера на вівторок у DC Phoenix»? Не зовсім, і я не впихатиму його в непов’язаний об’єкт лише для того, щоб сказати, що ми лишилися на стандартних. Маніфест → Manifest__c. Це одиниця отримання: звідки він прийшов (файл, пакет через API), коли, його статус і підсумки, а коли партнер надсилає його повторно в той самий день — що порівнюється. Кожен рядок маніфесту стає Work Order, пов’язаним із ним.

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

Click to enlarge

Крок 3 з 4: єдиний користувацький об’єкт — там, де жоден стандартний не підходить.

Фото: те, що Salesforce може це зберігати, не означає, що має

«Нам потрібні фото доставок у Salesforce». Що означає «у Salesforce»? Користувачам треба бачити їх із Salesforce — так. Чи означає це, що файли зображень мають жити в основному сховищі? Не обов’язково. Порахуйте нулі: приблизно чотири фото на доставку, більше з монтажем, при мільйоні доставок на рік — це чотири-п’ять мільйонів фото на рік, а доставки зростають на 30% на рік.

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

Поля: зробіть зміст видимим

Work Order потребує полів: номер партнера, вікно доставки, фактичний час доставки, статус, нотатки на кшталт «код від хвіртки» чи «у дворі собака». Я не перетворюватиму це на каталог полів; це зробив модуль 6. Проженіть кожне через запитання: що воно означає, хто ним володіє, чи змінюється воно, чи це ідентифікатор, контрольований словник, збережене чи похідне значення, чутливі дані. Номер партнера — це External ID, тож його унікальність — частина інтеграційного контракту, а не просто прапорець. Фактичний час доставки — момент часу, отже Date/Time. Статус керує поведінкою, отже контрольований список, ніколи не вільний текст. А нотатки про чийсь дім — персональні дані, тож їх класифікують. Кожне поле веде назад до змісту.

Зв’язки: не просто з’єднуйте прямокутники

Account до Work Order, Work Order до його рядків, Manifest до Work Order, Work Type, що описує зупинку. Потім запитання з модуля 7 для кожної лінії: чи може дочірній запис існувати сам, хто ним володіє, чи успадковується доступ, чи може він переміщатися, що стається при видаленні, скільки дочірніх записів може накопичитися? Кожен Work Order під кількома акаунтами роздрібних партнерів означає сотні тисяч дочірніх записів на батьківський — питання перекосу, на яке ми відповімо в частині 2. А для стандартних зв’язків Field Service перевірте, як Salesforce їх уже побудував, замість припускати, що вони збігаються з тим, що спроєктували б ми. Приймаючи стандартну модель, ви приймаєте рішення, які Salesforce ухвалив усередині неї. Розберіться в них, перш ніж будувати поверх.

Власність і отримувач: не дозволяйте вирішувати значенню за замовчуванням

Два рішення, які значення за замовчуванням охоче ухвалило б за нас.

Хто володіє доставкою? Ми відповіли на це в модулі 8, і відповідь переходить просто на Work Order: власність тут не визначає нічийого доступу, тож Work Orders, які створює інтеграційний користувач, належать йому. Диспетчери бачать ті, що належать їхньому розподільчому центру, бригади — ті, що на їхніх маршрутах, а кожен роздрібний партнер бачить свої через портал, і все це через спільний доступ, а не власність. Інтеграційний користувач не має ролі й лишається поза публічними групами, які використовують наші правила спільного доступу, бо при 3 300 на день він перевищує 10 000 записів за три дні. І ми записуємо, що станеться, якщо цього користувача колись замінять.

Що таке отримувач (Recipient)? Contact? Персональний акаунт? Щось, що зберігається лише в доставці? Це залежить від того, чи має Steve Trucking узагалі стосунки з цими людьми (вони клієнти роздрібних партнерів), чи може один партнер колись побачити клієнтів іншого, як довго можна зберігати їхні персональні дані, і від масштабу: близько мільйона нових отримувачів на рік. Усього цього в нас ще немає, і це нормально. Іноді правильна відповідь — ми ще знаємо недостатньо. Запишіть питання і підіть по інформацію; не ховайте невизначеність у користувацькому об’єкті. Ми відповідаємо на нього на контрольній точці Частини 1, коли розділи 4–6 дадуть нам картину підприємства й основних даних.

Узгодженість: захищайте модель на правильному рівні

Діє драбина з модуля 9: номер партнера — External ID, унікальний, тож повторно надісланий маніфест виконує upsert замість дублювання; статус — обмежений список; фактичний час доставки обов’язковий лише тоді, коли статус каже Delivered; зупинку з монтажем не можна закрити без чекліста й фото. Не один гігантський flow. Кожне правило на власному щаблі.

Де живе кожна частина

Ще один прохід по фрагменту, із запитанням модуля 4: де живе кожна частина даних? У моїй презентації для занять це один слайд, логічне проти фізичного: логічні сутності з розділу 2 і де кожна з них фізично опиняється: в ядрі, як sObject (__c, якщо користувацький) або big object (__b), чи поза ядром, як зовнішній об’єкт (__x) або дані, що взагалі ніколи не потрапляють у Salesforce.

• В ядрі, у щоденній роботі: Account, Work Orders та їхні рядки, Service Appointments, Work Types, Manifest__c.
• В ядрі, в архіві: доставки, старші за три роки, переходять у Delivery History, big object; вони досі там для претензій — у сараї на задньому дворі.
• За посиланням: власні деталі замовлення роздрібного партнера лишаються в системі партнера; ми зберігаємо номер партнера як External ID, а до решти дістаємося через зовнішній об’єкт чи інтеграцію, коли комусь це потрібно.
• Поза ядром: фото, у сховищі, побудованому для мільйонів зображень, із посиланням із Work Order.

Ось фізична модель: не лише який об’єкт, а й який дім.

Тепер подивіться на весь фрагмент

• Роздрібний партнер → Account з типом запису Retail Partner; керівники DC — контакти.
• Доставка → Work Order із Field Service, що планується через Service Appointment.
• Позиція доставки → Work Order Line Item.
• Вид зупинки → Work Type.
• Маніфест → користувацький Manifest__c.
• Номер партнера → External ID у Work Order, унікальний у межах партнера.
• Фото → зберігаються поза ядром; Salesforce зберігає посилання й позначку повноти.
• Історія доставок → в архів, у big object, через три роки.
• Власність → інтеграційний користувач, доступ — через спільний доступ (модуль 8).
• Отримувач → відкрите, для контрольної точки Частини 1.

Click to enlarge

Крок 4 з 4: увесь фрагмент — в ядрі, в архіві й поза ядром. Кожна лінія — lookup: Salesforce побудував Field Service на lookup, і ми приймаємо його рішення разом із ним.

Діаграма — це не архітектура

Я можу дати вам цю діаграму, і цього недостатньо. Архітектура — це обґрунтування за нею. Чому Account? Компанія з чистою відповідністю. Чому Work Order, а не Delivery__c? Доставка поводиться як польова робота, а Field Service уже на місці. Чому користувацький Manifest? Немає чистого стандартного дому. Чому фото — не просто Files? Обсяг і економіка сховища. Чому External ID? Іншій системі потрібна стабільна ідентичність через межу. Чому Work Orders належать інтеграційному користувачеві? Власність тут не визначає доступ, а так аудиторський слід лишається чесним. Чому отримувач досі відкритий? Ми ще не відповіли на достатньо питань. Лінії — це результат; їх породили рішення.

Тож ось звичка, з якою я хочу, щоб ви вийшли з розділу 3. Покажіть на будь-що у фізичній моделі й спитайте чому? Чому цей об’єкт, цей тип, цей зв’язок, цей власник, це місце, це правило? Ви маєте змогти простежити відповідь назад: від конфігурації до фізичної моделі, до логічної моделі, до бізнес-вимоги. Якщо не можете, хтось проєктував із Setup.

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

За межами іспиту: що змінює ШІ. Дайте ШІ бриф Steve Trucking — і він за секунди видасть схему: Account, Work Order, користувацькі об’єкти, поля, навіть метадані для розгортання. Це фантастичний прискорювач, але це не перевірка. Робота архітектора зміщується до перевірки відповідностей і їхніх наслідків: відповідність, ліцензії, власність, життєвий цикл, масштаб, ідентичність, безпека і те, що лишається поза платформою. ШІ — це ракетний прискорювач; він не скаже вам, чи ви націлені в правильному напрямку.

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

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

На початку цього розділу ми спитали, як модель має жити в Salesforce. Це і є архітектура даних Salesforce: не створення об’єктів, не заучування Setup, не малювання гарніших прямокутників, а свідоме припасування бізнес-моделі до форми платформи. Кожна структура — це зобов’язання. Беріть ті, які можете пояснити.

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

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) і WorkType (opens in a new tab) (англійською, перевірено 2026-10-02).
• Бриф Steve Trucking.