Стандартні моделі даних

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

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

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

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

Питання, на яке відповідає цей модуль: Що Salesforce уже змоделював за вас і як це влаштовано?

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

Що робить об’єкт стандартним

Стандартний об’єкт є «з коробки». Його побудував Salesforce, у нього визначене призначення, і він має власні поля й зв’язки. До нього можна додавати поля, будувати навколо нього автоматизацію і змінювати його макети, але переробити його не можна: стандартні поля й зв’язки належать Salesforce.

Подивіться на назви. Account, Contact, Case. Ні префікса, ні суфікса. Так Salesforce залишає цей простір за собою. Усе, що будуємо ми, закінчується на __c, тож Salesforce може будь-коли додавати нові стандартні об’єкти, ніколи не конфліктуючи ні з чим у вашій org. І він це робить у кожному релізі.

Колись хтось побудував об’єкт продукту, який не вдався, і його довелося залишити позаду. Тому API-назва — Product2. Це мій перший лакмусовий тест, коли хтось каже мені, що знає Salesforce.

Модель Sales

Почніть ліворуч, із Lead (ліда): людини, яка може стати клієнтом. Лід ще не зовсім частина моделі. Це зона очікування. Коли ви його конвертуєте, Salesforce створює справжні записи: Account (акаунт), Contact (контакт) і, якщо є угода, Opportunity (можливість). Тому я малюю лід осторонь.

Акаунт — це компанія. Його контакти — люди в ній. Можливість — угода з цим акаунтом. Поки що нічого несподіваного.

Далі стає цікаво. Що входить в угоду? Кожен рядок — це Opportunity Product, і Opportunity Product вказує не прямо на Product. Він вказує на Price Book Entry: цей продукт, за цією ціною, у цьому прайс-листі. Price Book Entry стоїть між Product і Price Book, тож той самий продукт може мати одну ціну в стандартному прайс-листі й іншу — у прайс-листі для партнерів.

Це два зв’язки, що стали сутностями, один за одним. Пам’ятаєте позицію доставки з розділу 2, між доставкою і продуктом, і Трюк собаки між Собакою і Трюком? Salesforce зробив тут те саме, двічі: Opportunity Product між Opportunity і Price Book Entry, і Price Book Entry між Product і Price Book. Коли ви вмієте це читати, ви можете прочитати більшу частину стандартної моделі даних.

Click to enlarge

Ось цей ланцюжок зблизька, з полями, що його тримають:

Click to enlarge

Одне правило, на якому спотикаються: є стандартний прайс-лист, і Price Book Entry в будь-якому іншому прайс-листі може просто використовувати стандартну ціну продукту. Знайте, який прайс-лист використовує можливість, перш ніж завантажувати її продукти.

Модель Service

Тепер інша половина дому. Той самий акаунт, ті самі контакти. Коли щось іде не так, клієнт відкриває Case (звернення).

Звернення зазвичай стосується чогось, що є в клієнта, і для цього в Salesforce є об’єкт: Asset (актив). У модулі 5 я назву його стандартним об’єктом, який люди не помічають. Це річ, яка є в клієнта, незалежно від того, купив він її у вас чи ні.

А на що клієнт має право? Це Entitlement: підтримка, на яку має право акаунт, часто прив’язана до активу, продукту чи сервісного контракту. Додайте entitlement до звернення — і звернення знає, який рівень підтримки йому належить.

Click to enlarge

Подивіться на лінію, що йде від Case назад до нього самого. Кожне звернення має поле Parent Case, і воно вказує на інше звернення. Це lookup на себе (self-lookup): зв’язок об’єкта з самим собою. Багатьох він збиває з пантелику, коли вони бачать його вперше, тож ось дві причини, з яких я його використовую.

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

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

До lookup на себе ми повернемося, коли дійдемо до зв’язків у модулі 7.

Зауважте, що Account і Contact стоять на тому самому місці на обох діаграмах. Це ті самі записи. Менеджер із продажів і агент сервісу дивляться на того самого клієнта з різних половин дому. Це один із найсильніших аргументів залишатися на стандартних об’єктах: моделі побудовано так, щоб вони зустрічалися.

Файли й вкладення

Не все в записі — поле. Контракти, фото, PDF і таблиці — це файли, і їм місце в Salesforce Files, а не в старій моделі Attachments, яка є застарілою. Якщо документ уже живе в SharePoint Online, OneDrive, Google Drive чи Box, Files Connect дає користувачам доступ до нього із Salesforce без копіювання.

Файли рахуються інакше, ніж записи. Salesforce ділить сховище на два: сховище файлів містить вкладення, Files, Salesforce CRM Content, файли Chatter тощо, а сховище даних — ваші записи. Сховище файлів швидко росте, коли до кожного запису додають фото чи скани, тож великі обсяги зображень, як-от фото з польового застосунку, часто краще тримати повністю поза Salesforce, а в Salesforce зберігати лише посилання. Модуль 4 повертається до цього.

Дві колонки чи двісті

Сховище даних теж рахується інакше, ніж у базі даних. У звичайній базі даних таблиця з двома колонками й мільйоном рядків мала, а таблиця зі ста колонками й мільйоном рядків — слон. Salesforce зважує їх однаково: більшість записів рахуються приблизно як 2 КБ, незалежно від кількості полів. Є винятки. Кампанія важить більше, email-повідомлення рахується за реальним розміром, а персональний акаунт — приблизно як 4 КБ, бо це акаунт і контакт.

Ось порада. Щоразу, коли я приходжу в нову org, одне з перших місць, куди я йду, — Setup → Storage Usage. Я навіть прошу клієнта надіслати скриншот на першому дзвінку. Цей екран не бреше. Він показує, які об’єкти ростуть і які вже стали слонами.

Персональні акаунти: коли клієнт — людина

Модель Account і Contact чудово працює для компанії та людей у ній. Але що, як ваш клієнт — не компанія? Що, як це людина?

Для цього є персональний акаунт (person account): акаунт і контакт, поєднані в один запис, для окремих людей. Їхні поля контакту йдуть разом із ним, а користувацькі показуються з власним суфіксом __pc. Кожен рахується і в сховищі акаунтів, і в сховищі контактів, бо всередині це і те, і те.

Одне застереження, перш ніж їх вмикати: після увімкнення персональних акаунтів вимкнути їх не можна. Це тест на зворотність із розділу 1 у найчистішому вигляді. Модуль 5 дає мою позицію щодо того, коли вони того варті.

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

• Які частини бізнесу Salesforce уже змоделював, ще до того, як проєктувати щось нове.
• Чи потрапляє концепція в модель Sales, модель Service чи в обидві, знаючи, що вони мають спільні Account і Contact.
• Де живуть документи й зображення: Salesforce Files, підключена файлова система чи поза платформою з посиланням.
• Скільки дані коштуватимуть у сховищі, якщо рахувати так, як рахує Salesforce: записами, а не колонками.
• Чи клієнт — компанія, чи людина, перш ніж вмикати те, що не можна вимкнути.

А коли в Salesforce немає того, що вам потрібно? Ви будуєте це самі. Про це далі.

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

• OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (англійською, перевірено 2026-10-12): “a member of the list of Product2 products associated with an Opportunity”; Price Book Entry обов’язковий.
• PricebookEntry (opens in a new tab), Object Reference (англійською, перевірено 2026-10-12): “an association between a Pricebook2 and Product2”; запис може використовувати стандартну ціну.
• Case (opens in a new tab), Object Reference (англійською, перевірено 2026-10-12): ParentId, “the ID of the parent case in the hierarchy. The label is Parent Case”; lookup на Case.
• Entitlement (opens in a new tab), Object Reference (англійською, перевірено 2026-10-12): “the customer support an account or contact is eligible to receive”, можливо, на основі активу, продукту чи сервісного контракту.
• Data and Storage Resources (opens in a new tab), Salesforce Help (англійською, перевірено 2026-10-12): що входить у сховище файлів і сховище даних.
• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (англійською, перевірено 2026-10-12): “Most Salesforce records consume approximately 2 KB of data storage”; персональні акаунти — приблизно 4 КБ.
• Enable Person Accounts (opens in a new tab), Salesforce Help (англійською, перевірено 2026-10-12): “After Person Accounts is enabled, it can’t be disabled.”
• Files Connect FAQ (opens in a new tab), Salesforce Help (англійською, перевірено 2026-09-25).