Краткий ответ

Качество архитектуры Salesforce определяется не количеством созданных компонентов, а способностью организации внедрять новый бизнес, продукты или выходить на новые рынки, не разрушая то, что уже функционирует. Наиболее распространенная проблема, с которой мы сталкиваемся, — это не ошибочный выбор технологии, а отсутствие документированного уровня принятия решений: кто является владельцем каждого объекта, почему выбран Flow, а не Apex, и почему существует пять отдельных интеграций вместо одного уровня Middleware.

Данная статья делит архитектуру на шесть слоев, которые необходимо проектировать совместно, а не изолированно: модель данных и объектов, совместный доступ и разрешения, автоматизация, интеграции, стратегия Org, а также DevOps со Scalability. Расширенные сведения об обработке ошибок интеграции представлены в статье Мониторинг интеграций Salesforce.

Модель данных и объектов: основа, на которой все строится

Распространенная ошибка во многих организациях: создание нового Custom Object для каждого поступающего бизнес-требования, без проверки возможности использования дополнительного поля в существующем объекте или Record Type. Результатом через два-три года является Org с 80-120 пользовательскими объектами, некоторые из которых дублируют друг друга по смыслу, без документации о причинах их создания.

Основной принцип – задавать вопросы перед созданием каждого объекта: кто является бизнес-владельцем, каков источник истины (Salesforce или внешняя система), и что происходит при удалении или дублировании записи. Например, компании, управляющие сложным каталогом продуктов, часто создают отдельный объект для каждой категории вместо использования Record Types для Product2, что приводит к излишней нагрузке на обслуживание при каждом обновлении.

Полезная таблица для проверки зрелости модели данных:

КомпонентПроверочный вопросПризнак предупреждения
Пользовательские объектыСуществует ли аналогичный объект, который можно расширить?Два объекта с преимущественно одинаковыми полями
ПоляИспользуется ли поле для более чем одного процесса?Более 800 полей в центральном объекте
СвязиВыбраны ли Master-Detail или Lookup намеренно?Master-Detail, выбранный «по умолчанию»
External IDИмеет ли каждый синхронизированный объект уникальный ключ?Синхронизация только по имени или дате

Совместный доступ и разрешения: уровень, который незаметно разрушается

Слабая модель разрешений обнаруживается не сразу — она проявляется, когда кто-то видит данные, которые не должен видеть, или когда в управленческом отчете отображается меньше строк, чем ожидалось, потому что Sharing Rule блокирует доступ. Выбор между Role Hierarchy, Organization-Wide Defaults, Sharing Rules и Permission Sets должен основываться на фактической структуре организации, а не на официальной иерархической структуре в организационной схеме.

Распространенный анти-паттерн: предоставление «View All» или «Modify All» на уровне профиля для «решения» проблемы с разрешениями в условиях нехватки времени, без последующего возврата и ограничения. Это работает в краткосрочной перспективе и создает широкое раскрытие информации в долгосрочной — особенно в регулируемых отраслях, таких как финансы или здравоохранение. Permission Set Groups позволяют создавать модульные разрешения, которые можно добавлять и удалять, не затрагивая базовый профиль, и это более безопасный способ работы с растущей организацией.

Criteria-Based Sharing Rules для объектов с миллионами записей требуют тестирования нагрузки перед Production — существуют случаи, когда, казалось бы, простое правило Shared приводит к пересчету, занимающему часы и останавливающему ночные процессы.

Автоматизация: Flow против Apex

Вопрос «Flow или Apex» — это вопрос не вкуса, а сложности, объема и срока службы. Flow более понятен для операционного отдела, создается и поддерживается быстрее, и подходит для изменяющейся бизнес-логики. Apex требуется, когда есть массовая обработка тысяч записей в одной транзакции, когда необходим точный контроль порядка выполнения по отношению к другим Triggers, или когда требуется автоматическое тестирование (Test Coverage) для регулирования или формального управления изменениями.

Частый анти-паттерн в растущих организациях: цепочки Flow, вызывающие друг друга (Flow, вызывающий Flow, вызывающий Flow), без центральной карты, показывающей порядок выполнения. Когда что-то ломается, никто не знает, какой Flow запустился первым. Пример из практики: организация с 14 активными Flows для Opportunity, три из которых имеют одинаковую логику обновления статуса, написанные в разное время разными людьми, без проверки того, что уже существует.

Практическое эмпирическое правило: если в одной бизнес-логике более 5-6 сложных условий или требуется внешний вызов внутри цикла, предпочтительнее Apex. В противном случае Flow предпочтительнее, потому что он доступен для обслуживания, даже если оригинальный разработчик уже не работает в компании.

Интеграции: от Point-to-Point к управляемому уровню

Организация, начинающая с двух внешних подключений (например, ERP и платежная система), обычно строит их напрямую, Point-to-Point, и это разумно на данном этапе. Проблема начинается, когда добавляется третье, четвертое и пятое подключение — каждое со своей логикой повторных попыток, обработки ошибок и сопоставления полей, без общего стандарта. На этом этапе любое изменение в исходной системе нарушает одно или несколько подключений, о чем никто заранее не знает.

Переход на уровень Middleware (MuleSoft или специализированный Integration Layer) не обязательно должен быть огромным проектом — можно начать с самого хрупкого или дорогостоящего в обслуживании подключения и постепенно переходить. Принципы, которые следует применять в каждой новой интеграции: Idempotency (повторный вызов не создает дублирующую запись), External ID для точной идентификации и журнал, позволяющий точно восстановить, что произошло при каждом вызове. Расширенные сведения о шаблонах интеграции представлены в статьях Подключение Salesforce к ERP и Шаблоны интеграции Salesforce.

Стратегия Org: Single Org, Multi-Org или сегментация бизнес-подразделений

Это одно из самых дорогих решений для последующей корректировки. Single Org с сегментацией бизнес-подразделений (использование Record Types, Sharing и Permission Sets для логического разделения) подходит для большинства организаций, поскольку он сохраняет единый источник истины и унифицированные показатели отчетности. Multi-Org целесообразен, когда бизнес-подразделения требуют существенно противоречивых моделей разрешений, когда происходит слияние или поглощение, приносящее существующий Org, или когда фактическая нагрузка на разрешения снижает производительность.

Переход между моделями после создания организации является сложным проектом — слияние данных, переназначение разрешений и иногда потеря истории. Полное описание соображений для принятия решения представлено в статье Salesforce Multi Org.

DevOps и Scalability: как поддерживать возможность изменений

Организация, которая разрабатывает непосредственно в Production, без упорядоченного Sandbox и без инструментов CI/CD (таких как Copado, Gearset или SFDX), быстро приходит к ситуации, когда каждое изменение опасно. Правильный процесс DevOps включает минимум Sandbox для разработки, Sandbox для тестирования, контроль версий для Metadata и автоматический процесс развертывания с регрессионным тестированием.

Таблица ключевых архитектурных решений и их долгосрочных последствий:

РешениеНемедленное преимуществоПоследствия через 2-3 года
Custom Object для каждого требованияБыстрое решение точечной проблемыOrg с десятками дублирующихся объектов, сложно поддерживать
Временные разрешения «View All»Решает проблему за минутыШирокое раскрытие информации, которое сложно отследить и закрыть
Flow, вызывающий FlowБыстрая разработка без кодаЦепочки, которые сложно отслеживать и тестировать
Дополнительная интеграция Point-to-PointБыстрое подключение между двумя системамиСеть подключений, где любое изменение ломает что-то другое
Разработка непосредственно в ProductionЭкономит время на настройку процессаВысокий риск для любого изменения, трудности с восстановлением
Single Org без логического разделенияЕдиная отчетность с первого дняТрудности с добавлением бизнес-единицы с различными потребностями

Пример организационного сценария

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

Архитектурная команда провела полное картирование: выявила 23 объекта без явного владельца, шесть перекрывающихся цепочек Flow и две интеграции, которые создавали дублирующиеся записи из-за отсутствия последовательного External ID. Решение заключалось не в перестройке, а в постепенном документировании, унификации логики Sharing с помощью Permission Set Groups и переходе критических интеграций на единый уровень Middleware. В течение двух кварталов время добавления нового бизнес-подразделения сократилось с нескольких месяцев до примерно шести недель.

Распространенные анти-паттерны в растущих организациях

  • Custom Object для каждого запроса — создание нового объекта без проверки наличия аналогичного.
  • «Временные» широкие разрешения — выдаются под давлением и никогда не сокращаются обратно.
  • Flow-in-Flow без картирования — цепочки автоматизации без центральной схемы выполнения.
  • Point-to-Point без Governance — каждое новое подключение строится отдельно без общего стандарта.
  • Разработка в Production — прямые изменения без Sandbox, тестирования или контроля версий.
  • Отсутствие External ID — синхронизация по имени или электронной почте, приводящая к дублированию записей.

Чек-лист для проверки зрелости архитектуры

  • ☐ Для каждого пользовательского объекта есть документированный бизнес-владелец.
  • ☐ Модель Sharing проверена под реалистичной нагрузкой данных.
  • ☐ Существует центральная карта всех цепочек автоматизации.
  • ☐ Для каждой интеграции есть External ID, Retry и журнал ошибок.
  • ☐ Существует упорядоченный процесс от Sandbox до Production с регрессионным тестированием.
  • ☐ Принято явное решение между Single Org и Multi-Org с письменным обоснованием.
  • ☐ Governor Limits проверяются относительно прогноза роста на три года.

Когда архитектура Salesforce требует профессионального сопровождения, а не только самостоятельной работы, это относится к области Услуги по архитектуре CRM.

Профессиональные источники