Краткий ответ
Качественная модель данных в Salesforce — это не самая теоретически идеальная модель, а та, которая одновременно поддерживает три аспекта: бизнес-процессы, модель разрешений и необходимую отчетность. Большинство неудачных моделей строились только вокруг первого аспекта.
Отличие решения по модели данных от других проектных решений заключается в стоимости изменений. Изменение Flow занимает день; изменение типа связи между объектами после двух лет накопленных данных, автоматизации и интеграций — это отдельный проект. Поэтому инвестиции на этапе планирования здесь окупаются больше, чем где-либо еще.
Первое правило: начинать со стандартных объектов
Account, Contact, Lead, Opportunity, Case и Product обладают возможностями, которые не доступны бесплатно для пользовательского объекта: процессы продаж, прогнозирование, права, Omni-Channel, мобильное приложение и встроенная интеграция с другими продуктами платформы.
Организация, которая создает Customer__c вместо Account, на начальном этапе получает более чистую модель, но затем обнаруживает, что каждая стандартная функция требует самостоятельной реализации. Правило: отступать от стандарта следует только при наличии причины, которую можно сформулировать одним предложением.
Когда требуется пользовательский объект
| Ситуация | Требуется ли пользовательский объект | Обоснование |
|---|---|---|
| Контракт/подписка с собственным жизненным циклом | Да | Отдельные статусы, продление, владение и отчетность |
| Установленное оборудование у клиента | Да (или стандартный Asset) | Самостоятельная сущность с историей обслуживания |
| Дополнительный "потенциальный клиент" | Нет | Это Lead или Account с Record Type |
| Отдел в организации | Нет | Данные о пользователе, а не отдельная сущность |
| Сложные ценовые позиции | Зависит | Перед созданием рассмотреть Quote Line или CPQ |
Нормализация против денормализации: решение, влияющее на отчетность
В классических базах данных нормализация является достоинством. В Salesforce она обменивается на удобство отчетности: каждый дополнительный уровень связи усложняет построение отчета без внешнего инструмента, поскольку стандартная отчетность ограничена глубиной связей.
Принятый компромисс — нормализация там, где данные изменяются и дублируются, и контролируемая денормализация часто используемых полей запросов в объект, из которого формируются отчеты, при условии, что дублирование управляется автоматически, а не вручную. Поле, дублирование которого обновляется вручную, становится некорректным в течение нескольких месяцев.
Разрешения — часть модели, а не последующий этап
Вопрос "кто что видит" должен задаваться на этапе проектирования объектов. Модель, в которой конфиденциальные данные находятся в том же объекте, что и операционные данные, впоследствии заставляет использовать обходные решения — теневой объект, зашифрованные поля или предоставление слишком широкого доступа.
Практическая проверка: для каждого нового объекта пишется одна строка — кто владелец, кто читает, кто изменяет и что происходит в иерархии. Если ответ требует более четырех строк, структура, вероятно, смешивает две сущности.
Более подробная информация об источниках данных и полномочиях по обновлению представлена в статье Source of Truth в организации, а об управлении основными данными — в Управление основными данными (MDM).
Сценарий: компания-разработчик ПО, построившая модель вокруг отделов
Средняя SaaS-компания построила модель с четырьмя пользовательскими объектами — по одному для каждой команды продаж — потому что каждая команда имела свой собственный процесс. Полтора года спустя произошло объединение команд, и тогда потребовались: унификация отчетов, параллельная автоматизация в четырех местах и внутренняя миграция 60 тысяч записей между объектами.
Перестройка основывалась на одном Opportunity с Record Types для разных процессов. Та же бизнес-логика была сохранена — разные процессы продаж, разные поля, разные Page Layouts — но на уровне конфигурации, а не структуры. Следующее организационное изменение потребует изменения Record Type, а не миграции.
Правило, вытекающее из этого: структура представляет сущности; конфигурация представляет организацию. То, что, как ожидается, будет меняться раз в два года, не должно быть частью структуры.
Производительность и объем — что действительно важно
Проблемы с производительностью в модели данных в основном возникают из трех источников: Data Skew (один родитель с десятками тысяч дочерних записей, например, Account "частные клиенты"), вложенные формулы, вычисляемые в реальном времени по связям, и совместное использование на основе Apex Sharing, созданное в большом объеме. Все три могут быть идентифицированы на этапе проектирования, если задать вопрос о предполагаемом количестве записей под каждым родителем.
Типичные риски и превентивные меры
| Риск | Как он проявляется на практике | Превентивные меры |
|---|---|---|
| Избыточный пользовательский объект | Стандартные функции реализуются вручную | Проверка стандартных объектов перед созданием нового |
| Master-Detail слишком рано | Каскадные удаления и неизменяемая структура | Начинать с Lookup, если не требуется Roll-Up |
| Модель, отражающая структуру организации | Каждое организационное изменение становится миграцией | Record Types вместо объектов |
| Data Skew | Блокировки и замедление при массовых обновлениях | Распределение родительских объектов, оценка объема на этапе планирования |
| Разрешения как запоздалая мысль | Обходные решения и слишком широкий доступ | Матрица доступа для каждого объекта на этапе планирования |
Как измерять успех
| Область | Что измеряется | Частота проверки |
|---|---|---|
| Использование полей | Процент заполнения для каждого поля | Ежеквартально |
| Отчетность | Процент отчетов, требующих ручной консолидации | Ежеквартально |
| Стабильность структуры | Количество структурных изменений за полгода | Раз в полгода |
| Производительность | Время массового обновления и блокировки | Ежемесячно |
Проектирование модели данных как части общей архитектуры осуществляется в рамках услуг интеграции и данных.
Контрольный список перед фиксацией модели
- ☐ Для каждого пользовательского объекта существует однословное обоснование
- ☐ Проверен альтернативный стандартный объект для каждой сущности
- ☐ Тип связи явно выбран с обоснованием для Master-Detail
- ☐ Оценочный объем для каждого родительского объекта (проверка на Skew)
- ☐ Матрица доступа: владелец, читатель, редактор, иерархия
- ☐ Проверено, что каждый центральный отчет может быть построен в модели
- ☐ Дублированные поля обновляются только автоматически
- ☐ Ожидаемые организационные изменения обрабатываются в конфигурации
- ☐ Существует актуальная и документированная ERD
- ☐ Определен ответственный за утверждение изменений структуры в будущем
Профессиональные источники
- Salesforce Data 360 — https://www.salesforce.com/data/
- Архитектура Salesforce Data 360 — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Интеграции и данные — https://hpi.pro/integrations-data