Выберите правильный объект

🌐 Также доступно на 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 встречается с платформой, и моя исходная позиция проста: если бизнес-понятие чисто соответствует назначению стандартного объекта, начинайте с него.

Начните со смысла

Даже если что-то заслуживает быть объектом, это не значит, что оно автоматически заслуживает быть пользовательским объектом. Спросите, что эта штука на самом деле представляет. Бизнес или организацию любой формы? Начните с организации (Account). Человека, который работает с этой организацией? Контакт. Что-то, чем клиент владеет или что он купил? Актив. Что-то, что вы пытаетесь продать? Тогда в разговор вступает возможность.

Вот почему мы сначала посмотрели на корабль-носитель, в модуле 2. Эти модели подходят не каждому бизнесу, но не стоит игнорировать их только потому, что построить свое кажется чище. Прежде чем нажать New Custom Object, спросите, как Salesforce моделирует это понятие, что построено вокруг этой модели и от чего вы откажетесь, если ее замените.

Тест на чистое соответствие

Мой тест — один вопрос: чисто ли это бизнес-понятие соответствует назначению стандартного объекта? Если да, я склоняюсь к стандартному объекту.

Дистрибьютор — это компания, с которой у нас есть отношения, поэтому Account подходит чисто. Меня не смущает, что пользователи называют одну компанию дистрибьютором, другую поставщиком, третью розничным партнером, а четвертую клиентом. Это бизнес-роли, и им не нужны четыре физических объекта. Разные бизнес-названия не означают автоматически разные структуры данных. Разницу может нести тип, тип записи или связь.

Тест работает и в обратную сторону. В главе 1 я оставил вам вопрос: у бизнеса клиента много адресов доставки. Каждый адрес должен быть организацией (Account) или пользовательским объектом?

Account дает вам многое. Вы получаете поля адреса и все, что уже ожидает адрес организации: отчеты, карты, интеграции. Но вы получаете и накладные расходы: множество полей, общий доступ, иерархию, владение — все, что висит на Account, и большая часть этого не нужна отдельному адресу. Вы бы тащили на себе много тяжелого, чем не будете пользоваться, ради одного альтернативного адреса.

Пользовательский объект, дочерний для организации, может быть легким: только поля адреса, место, куда мы доставляем, со своим жизненным циклом, которым я могу управлять независимо.

Так что это баланс: вес, который вы берете на себя, против ценности, которую получаете. Если мне нужен только адрес со своим жизненным циклом, здесь я выбираю пользовательский объект.

То же с подпроблемами обращения. Если каждая подпроблема действительно является обращением, которое ведет агент поддержки, со своим статусом и уровнем обслуживания, вкладывайте их через Parent Case из модуля 2. Но если это просто пункт чек-листа, который никто не ведет как обращение, полноценное обращение несет много такого, что никогда не понадобится, и простой пользовательский дочерний объект может весить меньше. Не потому, что пользовательский чище. А потому, что смысл другой или вес не тот.

Стандартные объекты приходят с багажом

Выбирая стандартный объект, вы выбираете больше, чем его поля. Вы выбираете то, что продукты Salesforce уже понимают: отчетность, автоматизацию, встроенные связи, функции продуктов, пакеты AppExchange и все, что Salesforce построит дальше. Это может быть невероятно ценно.

Но у стандартных объектов есть и свое мнение: существующее поведение, связи, вопросы безопасности, иногда требования к лицензиям и функции, которые вам не нужны. Поэтому «всегда используйте стандартные объекты» — не мое правило. У меня нет правил со словом «всегда». У меня есть склонность: используйте стандартный объект, когда смысл подходит чисто и поведение платформы вокруг него помогает дизайну, а не борется с ним. Если я пять лет заставляю Opportunity вести себя как что-то, что не является возможностью продажи, я ничего не выиграл, оставшись на стандартном. Я просто сделал неверный компромисс в другую сторону.

Актив — хороший пример

Актив (Asset) — один из стандартных объектов, которые люди упускают из виду. Проще всего я могу сказать так: это то, что есть у клиента. Может, он купил это у нас, может, нет. Мне все равно важен продукт конкурента, который стоит у моего клиента, потому что я его обслуживаю, или пытаюсь заменить, или мне нужно понимать их установленную базу. Если я создаю Customer_Product__c, не посмотрев сначала на Asset, я пропустил архитектурный вопрос. Asset не выигрывает автоматически, но заслуживает оценки.

Персональные учетные записи: когда человек — это организация?

В модуле 2 мы познакомились с персональными учетными записями: организация и контакт в одной записи, для клиентов — частных лиц. Теперь решение.

Моя позиция: для B2C без них трудно обойтись. С организациями и контактами из коробки приходит так много, что затраты и накладные расходы того стоят. А затраты есть: примерно вдвое больше хранилища, чем у бизнес-организации, переключатель, который нельзя выключить, и некоторые внешние лицензии не могут с ними работать. Partner Community нельзя использовать с персональными учетными записями (Experience Cloud User Licenses (opens in a new tab)). Так что вопрос не в том, «есть ли у нас люди в базе данных?» Люди есть в каждом org. Вопрос в том, «является ли человек в этом бизнесе действительно организацией-клиентом?» То, что контакт — человек, не делает его персональной учетной записью. Это делают деловые отношения.

Click to enlarge

А теперь я все усложню: лицензирование

Пока что: найдите понятие, ищите самое чистое стандартное соответствие, выбирайте пользовательский объект, когда смысл не подходит. Теперь следующий вопрос архитектора: кому нужно этим пользоваться? Можно спроектировать прекрасную модель и потом обнаружить, что у половины людей, которым нужны данные, нет лицензий на выбранные вами объекты. Лицензии — часть модели данных.

Три внутренние лицензии

Начнем с ваших собственных людей. Внутри компании есть три типа лицензий, которые каждый архитектор должен знать назубок, потому что они определяют, что каждый пользователь может видеть и делать, а значит, на что может рассчитывать ваша модель данных.

Sales Cloud (теперь Agentforce Sales). У этих пользователей полная пользовательская лицензия Salesforce: стандартные объекты CRM и любые стандартные или пользовательские приложения. Это интересы, возможности и прогнозы поверх организаций и контактов, и даже обращения: менеджер по продажам может посмотреть открытые обращения клиента перед звонком. Чтобы создавать и запускать кампании, нужна еще одна вещь — функциональная лицензия Marketing User.

Service Cloud (теперь Agentforce Service). Та же пользовательская лицензия Salesforce, настроенная для обслуживания. В центре — обращения, с которыми работают в Service Console: именно функциональная лицензия Service Cloud User открывает Salesforce Console for Service. Здесь живут соглашения об уровне обслуживания (SLA) — через управление правами на обслуживание и вехи (milestones), — и здесь появляется Knowledge, который большинство редакций покупают как дополнение.

Platform (Salesforce Platform). Для людей, которым нужны ваши пользовательские приложения, а не CRM. Они получают организации, контакты, отчеты, дашборды, документы и все пользовательские приложения в org. Чего они не получают: прогнозов, интересов, кампаний и возможностей. Она дешевле — именно поэтому на ней работает так много больших пользовательских приложений, и именно поэтому она может подловить вашу модель данных.

	Sales Cloud	Service Cloud	Platform
Пользовательская лицензия	Salesforce	Salesforce	Salesforce Platform
Для чего создана	Продажи	Поддержка клиентов	Пользовательские приложения
Организации, контакты	Да	Да	Да
Интересы, возможности, прогнозы	Да	Да	Нет
Обращения	Да, чтобы видеть обращения клиента	В центре, в Service Console	Нет
Соглашения об уровне обслуживания	Нет	Да, права на обслуживание и вехи	Нет
Пользовательские объекты и приложения	Да	Да	Да

Читайте таблицу так, как читает архитектор. Если большая группа пользователей сидит на Platform, любой дизайн, который помещает их работу в возможность, сломан еще до старта. Если руководителям нужны показатели SLA, то, увидят ли они их, решает их лицензия. Эти три типа определяют поведение.

Click to enlarge

Когда объект решает лицензия

Возможность (Opportunity) — жертва, с которой я сталкивался чаще всего. Вы видели это в таблице: пользователи Platform ее не получают (Standard User Licenses (opens in a new tab)), и пользователи Customer Community тоже не могут с ней работать. Требование выглядит как возможность, кто-то говорит: «Давайте использовать Opportunity», и тогда я спрашиваю, кому нужен доступ. Если большая группа сидит на лицензиях Platform или Customer Community, лицензия — уже не деталь закупки. Это архитектурное ограничение, и обычно оно толкает дизайн к пользовательскому объекту.

Это работает и вверх. На занятиях я спрашиваю: генеральный директор хочет красивые дашборды; лицензия Sales или Service? Пользователь Sales видит объекты продаж и даже обращения, так что для дашбордов продаж и количества открытых обращений Sales подойдет. Но как только руководитель хочет KPI по SLA (сколько времени осталось, пока обращение не нарушит уровень обслуживания), эти данные лежат в правах на обслуживание и вехах, а для управления правами на обслуживание нужен Agentforce Service, бывший Service Cloud (Supported Editions for Service Features (opens in a new tab)). Теперь вы повышаете лицензии руководителей. Слушайте бизнес-требование и знайте, какая лицензия стоит под нужными ему данными.

Стадион

Я думаю о лицензиях как о местах на стадионе. Все смотрят одну и ту же игру. Если я покупаю дорогие места в центре, я вижу обе команды вблизи. Если я сижу наверху в углу на открытой трибуне, сиденья без подушек, и я смотрю в бинокль.

Это внешние лицензии, для людей за пределами компании: клиентов и партнеров, которые входят на сайт Experience Cloud. Есть три, которые я хочу, чтобы вы знали.

Customer Community: открытая трибуна. Создана для большого числа внешних пользователей, которым нужны обращения и база знаний: клиент проверяет свое обращение в поддержку. Места стоят примерно вдвое дешевле и могут достаться огромному числу пользователей. Что вы теряете там наверху? Отчеты, дашборды и таблицу общего доступа — общий доступ на основе ролей, который получают более высокие уровни. С персональными учетными записями она работает.

Customer Community Plus: примерно на полпути вниз. Salesforce описывает ее как лицензию для внешних пользователей, которым нужны отчеты, дашборды и стандартный общий доступ: клиент, который управляет доступом других людей или должен видеть свои показатели.

Partner Community: еще ближе, для B2B, с доступом к данным продаж. Партнеры работают с интересами и возможностями: регистрируют сделки и проводят с вами кампании. Это внешнее место, которое дотягивается до объектов продаж. Одна загвоздка: ее нельзя использовать с персональными учетными записями (Experience Cloud User Licenses (opens in a new tab)).

Click to enlarge

Ошибка — проектировать так, будто у всех дорогой билет, а потом на внедрении обнаружить, что большинство ваших пользователей не могут попасть в сектор, куда вы положили их данные. Тогда у вас три варианта: купить другие места, перенести опыт работы или перепроектировать модель. Все три — архитектура.

То, как они платят, меняет дизайн

Есть еще один вопрос, о котором забывают: как эти пользователи будут входить? Внешние лицензии бывают двух видов. По участникам (member-based): вы платите за пользователя, что подходит 500 партнерам, которые входят каждый день. По входам (login-based): вы покупаете число входов в месяц, что подходит пяти миллионам клиентов, которые входят несколько раз в год. Несколько входов в один и тот же день считаются одним входом (Experience Cloud User Licenses (opens in a new tab)).

Поэтому, когда кто-то говорит «мы строим клиентский портал», мой следующий вопрос — не какой шаблон. А: кто эти клиенты, сколько их, как часто они приходят, какие данные им нужны и что им разрешено с ними делать?

Когда лицензия формирует модель

Иногда лицензия не просто выбирает объект; она изгибает всю модель. Некоторые лицензии Platform ограничивают пользователей одним пользовательским приложением максимум из десяти пользовательских объектов (например, Lightning Platform – One App; Standard User Licenses (opens in a new tab)).

На одном раннем проекте, для крупной компании в сфере профессиональных услуг и строительства, нам нужно было построить что-то вроде LinkedIn для всего персонала: должности, навыки, сертификаты, языки и проекты каждого, чтобы можно было найти строителя мостов с сертификатом в нужной стране. Без ограничения я бы построил объекты «пользователь — должность», «пользователь — навык», «пользователь — сертификат», «пользователь — язык» и «пользователь — проект», плюс справочные списки сертификатов и проектов. С лицензией на десять объектов, да еще с просьбой не расходовать их все, это было невозможно. Так что началась игра «угадай мелодию»: из скольких объектов минимум я могу это построить? Ответ был — из двух. Один справочный объект с типом записи для каждого вида списка (должность, навык, сертификат, язык, проект) и один объект атрибутов пользователя с соответствующими типами записей, указывающий на него.

Это была не оптимальная модель. По ней было мучительно строить отчеты, и я бы предпочел что-то чище. Но лицензия позволяла только это. Я называю такие объекты объектами — швейцарскими ножами: держите этот паттерн в заднем кармане, и когда лимиты не оставляют места, разбейте стекло и переходите к разделению по типам записей. Просто знайте, чем вы жертвуете. Разные разрешения по типам записей все равно могут заставить вас разделить объект.

Пользователи — теперь не только люди

Еще один вопрос о лицензиях стал важным: как быть с тем, что не является людьми? У интеграций есть учетные записи. У агентов есть учетные записи. Теперь у Salesforce есть лицензия Salesforce Integration для интеграций система — система: только API, не для людей, по пять включено в каждый org редакций Enterprise, Unlimited и Performance (Standard User Licenses (opens in a new tab)). Поэтому спрашивайте не только, каким пользователям нужен доступ. Спрашивайте, каким учетным записям он нужен: человеку, клиенту, партнеру, интеграции, агенту. А затем — что каждой из них нужно видеть и делать.

За пределами экзамена: что меняет ИИ. Когда агенты становятся еще одним потребителем и создателем данных, выбор объекта и лицензирование касаются уже не только экранов для людей. Знайте, от имени какой учетной записи работает агент, до чего эта учетная запись может дотянуться и не прячет ли модель нужные агенту данные за объектом или разрешением, которое ему недоступно.

Steve Trucking: один простой случай и один трудный

Steve Trucking работает с розничными партнерами (Retail Partners). Что такое розничный партнер? Бизнес. Легко: Account. Я не создаю Retail_Partner__c только потому, что кто-то употребил слово «партнер».

Теперь получатель (Recipient) — человек, который получает холодильник. Контакт? Персональная учетная запись? Что-то еще? Миллион новых получателей в год, и это клиенты розничных партнеров, а не наши. Это ровно такой вопрос, где я не хочу прыгать к объекту, пока не пойму отношения, доступ и масштаб. Мы решим это на контрольной точке Части 1.

Что здесь решает архитектор

• Чисто ли бизнес-понятие соответствует назначению стандартного объекта, или его смысл или вес другой.
• Являются ли разные бизнес-названия разными сущностями или просто разными ролями одной и той же.
• Может ли каждый человек, внешний пользователь, интеграция и агент, которым нужны данные, добраться до выбранного объекта при запланированных лицензиях.
• Как численность пользователей и характер входа (по участникам или по входам) определяют лицензию и модель.
• Когда лимит лицензии оправдывает не самую оптимальную модель и чего этот компромисс стоит в отчетности и разрешениях.

Смысл не в том, что стандартные объекты хорошие, а пользовательские плохие. А в том, что у выбора есть последствия, и иногда его решает вовсе не существительное, а люди — и машины, — которым нужно этим пользоваться.

Дополнительно

• Salesforce Help, Standard User Licenses (opens in a new tab), на английском, проверено 2026-10-02, перепроверено 2026-10-12: пользователям Platform не положены прогнозы, интересы, кампании и возможности; одно пользовательское приложение максимум из 10 пользовательских объектов; пять лицензий Salesforce Integration в каждом org редакции Enterprise.
• 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: соглашения об уровне обслуживания (управление правами на обслуживание) с 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 — для создания кампаний и управления ими.