Оберіть правильний об’єкт
Також доступно 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)
Модуль 5 з 10 розділу Архітектура даних Salesforce, розділ 3 курсу Data Architect. Кожен модуль самостійний. Попередній: Де живуть ці дані? · Наступний: Поля — це теж архітектура
Питання, на яке відповідає цей модуль: Яким об’єктом Salesforce має стати це бізнес-поняття і що дозволяють ліцензії?
Одна з найлегших речей у Salesforce — створити користувацький об’єкт. Саме тому, на мою думку, ми створюємо їх забагато.
Ви на сесії з вимог, і хтось каже: «Нам треба відстежувати наших дистриб’юторів». Новий користувацький об’єкт: Distributor. Готово. От тільки я хочу, щоб архітектор спершу поставив інше запитання: що таке дистриб’ютор? Це компанія. У Salesforce уже є досить добрий спосіб відобразити компанію. Він називається Account. Це не означає, що відповідь завжди Account. Але якщо мені треба пояснити, чому компанія не є Account, я хочу кращої причини, ніж «бізнес називає їх дистриб’юторами».
Тут логічна модель із розділу 2 зустрічається з платформою, і моя відправна позиція проста: якщо бізнес-поняття чисто відповідає призначенню стандартного об’єкта, почніть із нього.
Почніть зі змісту
Section titled “Почніть зі змісту ”Навіть коли щось заслуговує бути об’єктом, воно не заслуговує автоматично бути користувацьким об’єктом. Запитайте, що ця річ насправді представляє. Компанію чи організацію будь-якої форми? Почніть з Account. Людину, що працює з цією організацією? Contact. Щось, чим клієнт володіє або що купив? Asset. Щось, що ви намагаєтеся продати? Тепер у розмові з’являється Opportunity.
Ось чому ми спершу подивилися на материнський корабель, у модулі 2. Ці моделі пасують не до кожного бізнесу, але ми не повинні ігнорувати їх лише тому, що власна здається чистішою. Перш ніж натиснути New Custom Object, запитайте, як Salesforce моделює це поняття, що збудовано навколо цієї моделі і від чого ви відмовитеся, якщо її заміните.
Тест чистої відповідності
Section titled “Тест чистої відповідності ”Мій тест — одне запитання: чи чисто відповідає це бізнес-поняття призначенню стандартного об’єкта? Якщо так, я схиляюся до стандартного об’єкта.
Дистриб’ютор — компанія, з якою в нас є стосунки, тож Account — чиста відповідність. Мені байдуже, що користувачі називають одну компанію дистриб’ютором, іншу постачальником, ще іншу роздрібним партнером, а ще іншу клієнтом. Це бізнес-ролі, і їм не потрібні чотири фізичні об’єкти. Різні бізнес-назви не означають автоматично різних структур даних. Різницю може нести тип, тип запису чи зв’язок.
Тест працює і в інший бік. У розділі 1 я лишив вам запитання: бізнес клієнта має багато адрес доставки. Чи має кожна адреса бути Account, чи користувацьким об’єктом?
Account дає вам багато. Ви отримуєте поля адреси і все, що вже очікує адресу Account: звіти, карти, інтеграції. Але ви отримуєте й накладні витрати: багато полів, спільний доступ, ієрархію, власність, усе, що висить на Account, і більшість цього не стосується окремої адреси. Ви тягнули б багато важких речей, якими не користуватиметеся, лише заради альтернативної адреси.
Користувацький об’єкт, дочірній до Account, може бути легким: лише поля адреси, місце, куди ми доставляємо, з власним життєвим циклом, яким я можу керувати незалежно.
Тож це баланс: вага, яку ви на себе берете, проти цінності, яку отримуєте. Якщо мені потрібна лише адреса з власним життєвим циклом, тут я обираю користувацький об’єкт.
Те саме з підпитаннями до звернення. Якщо кожне підпитання справді є зверненням, яке опрацьовує агент, із власним статусом і рівнем обслуговування, вкладайте їх через Parent Case з модуля 2. Але якщо це лише пункт чек-листа, який ніхто не опрацьовує як звернення, повноцінне звернення несе багато того, чим ніколи не скористається, і простий користувацький дочірній об’єкт може важити менше. Не тому, що користувацьке чистіше. А тому, що зміст інший або вага не та.
Стандартні об’єкти приходять із багажем
Section titled “Стандартні об’єкти приходять із багажем ”Обираючи стандартний об’єкт, ви обираєте більше, ніж його поля. Ви обираєте щось, що продукти Salesforce уже розуміють: звітність, автоматизацію, вбудовані зв’язки, функції продуктів, пакети AppExchange і те, що Salesforce збудує далі. Це може бути надзвичайно цінно.
Стандартні об’єкти також мають власні погляди: наявну поведінку, зв’язки, міркування безпеки, іноді вимоги до ліцензій і функції, які вам не потрібні. Тож «завжди використовуйте стандартні об’єкти» — не моє правило. У мене немає правил «завжди». У мене є схильність: використовуйте стандартний об’єкт, коли зміст чисто відповідає, а поведінка платформи навколо нього допомагає дизайну, а не бореться з ним. Якщо я п’ять років змушуватиму Opportunity поводитися як щось, що не є можливістю продажу, я нічого не виграв, лишившись на стандартному. Я просто зробив хибний компроміс в інший бік.
Asset — добрий приклад
Section titled “Asset — добрий приклад ”Asset — один зі стандартних об’єктів, який люди пропускають. Найпростіше, як я можу сказати: це річ, яку має клієнт. Може, він купив її в нас, а може, ні. Мене все одно цікавить продукт конкурента, що стоїть у мого клієнта, бо я його обслуговую, або намагаюся замінити, або мені треба розуміти встановлену в нього базу. Якщо я створюю Customer_Product__c, не подивившись спершу на Asset, я пропустив архітектурне запитання. Asset не виграє автоматично, але заслуговує на оцінку.
Персональні акаунти: коли людина — це акаунт?
Section titled “Персональні акаунти: коли людина — це акаунт? ”У модулі 2 ми познайомилися з персональними акаунтами: акаунт і контакт в одному записі, для клієнтів, які є окремими людьми. Тепер рішення.
Моя позиція: для B2C без них важко обійтися. З Accounts і Contacts «з коробки» приходить стільки всього, що ціна й накладні витрати того варті. А ціна є: приблизно вдвічі більше сховища, ніж для бізнес-акаунта, перемикач, який не можна вимкнути, і деякі зовнішні ліцензії не можуть ними користуватися. Partner Community не можна використовувати з персональними акаунтами (Experience Cloud User Licenses (opens in a new tab)). Тож питання не «чи є в нашій базі люди?» Люди є в кожній org. Питання — «чи справді людина є акаунтом у цьому бізнесі?» Те, що Contact — людина, не робить його персональним акаунтом. Це робить бізнес-стосунок.
А тепер я все ускладню: ліцензування
Section titled “А тепер я все ускладню: ліцензування ”Досі: знайдіть поняття, шукайте найчистішу стандартну відповідність, переходьте до користувацького, коли зміст не пасує. Тепер наступне запитання архітектора: кому треба цим користуватися? Можна спроєктувати прекрасну модель, а потім виявити, що половина людей, яким потрібні дані, не має ліцензій на обрані вами об’єкти. Ліцензії — частина моделі даних.
Три внутрішні ліцензії
Section titled “Три внутрішні ліцензії ”Почніть зі своїх людей. Усередині компанії є три типи ліцензій, які я хочу, щоб кожен архітектор знав напам’ять, бо вони визначають, що кожен користувач може бачити й робити, а отже, на що може розраховувати ваша модель даних.
Sales Cloud (тепер Agentforce Sales). Ці користувачі мають повну ліцензію користувача Salesforce: стандартні CRM-об’єкти і будь-який стандартний чи користувацький застосунок. Це ліди, можливості й прогнози на додачу до акаунтів і контактів, і навіть звернення: менеджер із продажів може побачити відкриті звернення клієнта перед дзвінком. Щоб створювати й запускати кампанії, потрібна ще одна деталь — функціональна ліцензія Marketing User.
Service Cloud (тепер Agentforce Service). Та сама ліцензія користувача Salesforce, налаштована для обслуговування. Звернення в центрі, і з ними працюють у Service Console: саме функціональна ліцензія Service Cloud User відкриває Salesforce Console for Service. Тут живуть угоди про рівень обслуговування (SLA), через керування entitlements і milestones, і тут з’являється Knowledge, яку більшість редакцій купує як доповнення.
Platform (Salesforce Platform). Для людей, яким потрібні ваші користувацькі застосунки, а не CRM. Вони отримують акаунти, контакти, звіти, дашборди, документи і кожен користувацький застосунок в org. Чого вони не отримують: прогнозів, лідів, кампаній і можливостей. Вона дешевша — саме тому на ній працює стільки великих користувацьких застосунків, і саме тому вона може підставити вашу модель даних.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| Ліцензія користувача | Salesforce | Salesforce | Salesforce Platform |
| Для чого | Продажі | Підтримка клієнтів | Користувацькі застосунки |
| Акаунти, контакти | Так | Так | Так |
| Ліди, можливості, прогнози | Так | Так | Ні |
| Звернення | Так, щоб бачити звернення клієнта | У центрі, у Service Console | Ні |
| Угоди про рівень обслуговування | Ні | Так, entitlements і milestones | Ні |
| Користувацькі об’єкти й застосунки | Так | Так | Так |
Читайте таблицю так, як читає архітектор. Якщо велика група користувачів на Platform, будь-який дизайн, що кладе їхню роботу на Opportunity, зламаний ще до старту. Якщо керівникам потрібні цифри SLA, саме їхня ліцензія вирішує, чи зможуть вони їх побачити. Ці три типи визначають поведінку.
Коли ліцензія обирає об’єкт
Section titled “Коли ліцензія обирає об’єкт ”Opportunity — жертва, на яку я натрапляв найчастіше. Ви бачили це в таблиці: користувачі Platform її не отримують (Standard User Licenses (opens in a new tab)), і користувачі Customer Community теж не можуть із нею працювати. Тож вимога схожа на Opportunity, хтось каже «використаймо Opportunity», а потім я питаю, кому потрібен доступ. Якщо велика частина людей на ліцензіях Platform чи Customer Community, ліцензія вже не деталь закупівлі. Це архітектурне обмеження, і зазвичай воно штовхає дизайн до користувацького об’єкта.
Працює й угору. На заняттях я питаю: CEO хоче гарні дашборди; ліцензія Sales чи Service? Користувач Sales бачить об’єкти продажів і навіть звернення, тож для дашбордів продажів і кількості відкритих звернень Sales годиться. Але щойно керівник хоче KPI за SLA (скільки часу до порушення рівня обслуговування звернення), ці дані лежать в entitlements і milestones, а керування entitlements потребує Agentforce Service, колишнього Service Cloud (Supported Editions for Service Features (opens in a new tab)). Тепер ви підвищуєте ліцензії керівників. Слухайте бізнес-вимогу і знайте, яка ліцензія лежить під даними, які їй потрібні.
Стадіон
Section titled “Стадіон ”Я думаю про ліцензії як про місця на стадіоні. Усі дивляться ту саму гру. Якщо я купив дорогі місця посередині, я бачу обидві команди зблизька. Якщо я в кутку на трибунах, сидіння не м’які, і я дивлюся в бінокль.
Це зовнішні ліцензії — для людей поза компанією: клієнтів і партнерів, які входять на сайт Experience Cloud. Я хочу, щоб ви знали три з них.
Customer Community: трибуни. Створена для великої кількості зовнішніх користувачів, яким потрібні звернення й knowledge: клієнт перевіряє своє звернення до підтримки. Місця коштують приблизно вдвічі менше і можуть видаватися величезній кількості користувачів. Що ви втрачаєте нагорі? Звіти, дашборди і таблицю спільного доступу — спільний доступ на основі ролей, який отримують вищі рівні. З персональними акаунтами вона працює.
Customer Community Plus: приблизно на півдорозі вниз. Salesforce описує її як ліцензію для зовнішніх користувачів, яким потрібні звіти й дашборди та стандартний спільний доступ: клієнт, який керує доступом інших людей або має бачити свої цифри.
Partner Community: ще ближче, для B2B, з доступом до даних продажів. Партнери працюють із лідами й можливостями: реєструють угоди і проводять кампанії разом із вами. Це зовнішнє місце, яке дістає до об’єктів продажів. Одна заковика: її не можна використовувати з персональними акаунтами (Experience Cloud User Licenses (opens in a new tab)).
Помилка — проєктувати так, ніби в усіх дорогий квиток, а під час впровадження виявити, що більшість користувачів не може потрапити в сектор, де ви поклали їхні дані. Тоді у вас три варіанти: купити інші місця, перенести досвід або перепроєктувати модель. Усі три — архітектура.
Те, як вони платять, змінює дизайн
Section titled “Те, як вони платять, змінює дизайн ”Є ще одне запитання, яке забувають: як ці користувачі входитимуть у систему? Зовнішні ліцензії бувають двох видів. Member-based: ви платите за користувача, що пасує 500 партнерам, які входять щодня. Login-based: ви купуєте кількість входів на місяць, що пасує п’яти мільйонам клієнтів, які входять кілька разів на рік. Кілька входів того самого дня рахуються як один вхід (Experience Cloud User Licenses (opens in a new tab)).
Тож коли хтось каже «ми будуємо клієнтський портал», моє наступне запитання — не про шаблон. Воно таке: хто клієнти, скільки їх, як часто вони приходять, які дані їм потрібні і що їм дозволено з ними робити?
Коли ліцензія формує модель
Section titled “Коли ліцензія формує модель ”Іноді ліцензія не лише обирає об’єкт; вона гне всю модель. Деякі ліцензії платформи обмежують користувачів одним користувацьким застосунком із щонайбільше десятьма користувацькими об’єктами (наприклад, Lightning Platform – One App; Standard User Licenses (opens in a new tab)).
На одному з ранніх проєктів, для великої компанії професійних послуг і будівництва, нам треба було збудувати щось на кшталт LinkedIn для всього персоналу: посади, навички, сертифікації, мови й проєкти кожного, щоб можна було знайти будівельника мостів із сертифікацією в певній країні. Без ліміту я збудував би об’єкти «користувач — посада», «користувач — навичка», «користувач — сертифікація», «користувач — мова» і «користувач — проєкт», плюс довідкові переліки сертифікацій і проєктів. За ліцензії на десять об’єктів, і з проханням не витрачати їх усі, це було неможливо. Тож це стало грою «вгадай мелодію»: зі скількох найменше об’єктів я можу це збудувати? Відповідь — із двох. Один довідковий об’єкт із типом запису для кожного виду переліку (посада, навичка, сертифікація, мова, проєкт) і один об’єкт атрибутів користувача з відповідними типами записів, що на нього посилається.
Це не була оптимальна модель. Звітувати за нею було мукою, і я волів би чистішої. Але це те, що дозволяла ліцензія. Я називаю такі об’єкти об’єктами-швейцарськими ножами: тримайте цей шаблон у задній кишені, і коли ліміти не лишають місця, розбийте скло й переходьте до розділення типами записів. Просто знайте, чим платите. Різні дозволи для різних типів записів можуть усе одно змусити вас розділити об’єкт.
Люди вже не єдині користувачі
Section titled “Люди вже не єдині користувачі ”Ще одне запитання про ліцензування стало важливим: а як щодо того, що не є людьми? Інтеграції мають ідентичності. Агенти мають ідентичності. У Salesforce тепер є ліцензія Salesforce Integration для інтеграцій «система — система»: лише API, не для людей, по п’ять у кожній org редакцій Enterprise, Unlimited і Performance (Standard User Licenses (opens in a new tab)). Тож питайте не лише, яким користувачам потрібен доступ. Питайте, яким ідентичностям він потрібен: людині, клієнтові, партнерові, інтеграції, агентові. А потім — що кожна з них має бачити й робити.
За межами іспиту: що змінює ШІ. Оскільки агенти стають ще одним споживачем і творцем даних, вибір об’єкта й ліцензування — це вже не лише про людські екрани. Знайте, під якою ідентичністю працює агент, до чого ця ідентичність може дістатися і чи не ховає модель потрібні йому дані за об’єктом чи дозволом, яким він не може користуватися.
Steve Trucking: одне легке і одне складне
Section titled “Steve Trucking: одне легке і одне складне ”Steve Trucking працює з роздрібними партнерами. Що таке роздрібний партнер? Компанія. Легко: Account. Я не створюю Retail_Partner__c через те, що хтось ужив слово «партнер».
Тепер отримувач, людина, що отримує холодильник. Contact? Персональний акаунт? Щось інше? Мільйон нових отримувачів на рік, які є клієнтами роздрібних партнерів, а не нашими. Це саме той тип запитання, де я не хочу стрибати до об’єкта, перш ніж зрозумію стосунок, доступ і масштаб. Ми вирішимо це на контрольній точці Частини 1.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Чи чисто відповідає бізнес-поняття призначенню стандартного об’єкта, чи його зміст або вага інші.
- Чи різні бізнес-мітки — це різні сутності, чи лише різні ролі тієї самої.
- Чи кожна людина, зовнішній користувач, інтеграція й агент, яким потрібні дані, можуть дістатися до обраного об’єкта за запланованих ліцензій.
- Як кількість користувачів і шаблон входів (member-based чи login-based) формують ліцензію і модель.
- Коли ліміт ліцензії виправдовує неоптимальну модель і чого цей компроміс коштує у звітності й дозволах.
Суть не в тому, що стандартні об’єкти добрі, а користувацькі погані. Суть у тому, що вибір має наслідки, і іноді його вирішує зовсім не іменник, а люди — і машини, — яким треба цим користуватися.
Додаткові матеріали
Section titled “Додаткові матеріали ”- Salesforce Help, Standard User Licenses (opens in a new tab) (англійською, перевірено 2026-10-02, повторно 2026-10-12): користувачі Platform не мають права на прогнози, ліди, кампанії й можливості; один користувацький застосунок до 10 користувацьких об’єктів; п’ять ліцензій Salesforce Integration в кожній org редакції Enterprise Edition.
- Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (англійською, перевірено 2026-10-02, повторно 2026-10-12): Partner Community не можна використовувати з персональними акаунтами; Customer Community Plus — для звітів, дашбордів і стандартного спільного доступу; кілька входів за день рахуються як один.
- Salesforce Help, Supported Editions for Service Features (opens in a new tab) (англійською, перевірено 2026-10-02, повторно 2026-10-12): угоди про рівень обслуговування (керування entitlements) з Agentforce Service; Knowledge — додаткова вартість у більшості редакцій.
- Salesforce Help, Available Feature Licenses (opens in a new tab) (англійською, перевірено 2026-10-12): Service Cloud User — «доступ до Salesforce Console for Service»; Marketing User — для створення кампаній і керування ними.