Представьте: вы ведёте учёт объектов недвижимости, заявок на ремонт или рекламаций. CRM Битрикс24 даёт фиксированный набор сущностей — лиды, сделки, контакты, компании. Ни одна не подходит. Мы, команда разработчиков с 10-летним опытом, сталкивались с этим десятки раз. Начинается подгонка: поля называются не тем, что они значат, стадии воронки описывают не продажу, а что-то другое. Смарт-процессы (Smart Process Automation, SPA) решают эту проблему, но их настройка по умолчанию покрывает лишь 60% кейсов. Остальные 40% требуют кастомной разработки. Мы уже реализовали более 50 таких проектов для e-commerce, производства и услуг — гарантируем, что ваш процесс впишется в CRM без компромиссов. Экономия от автоматизации с помощью кастомного смарт-процесса может достигать $1.8k–2.6k в год за счёт сокращения ручного ввода данных и снижения ошибок. А скорость обработки заявок возрастает в 3 раза по сравнению с работой через сделки-костыли. Закажите предварительный аудит ваших процессов — мы предложим решение за 1 день.
Как разработать кастомный тип CRM-сущности в Битрикс24?
Смарт-процесс — это пользовательский тип CRM-сущности. Создаётся через CRM → Настройки → Автоматизация → Смарт-процессы. Каждый получает числовой entityTypeId (начиная с 128) и хранит элементы в таблице b_crm_dynamic_items_{entityTypeId}.
Программно смарт-процесс описывается классом \Bitrix\Crm\Service\Factory\Dynamic. Фабрика управляет жизненным циклом элементов: создание, обновление, удаление, перемещение по стадиям. Для получения фабрики:
$factory = \Bitrix\Crm\Service\Container::getInstance() ->getFactory($entityTypeId); Доступно из коробки:
- Пользовательские поля (UF-поля) любых типов — строка, число, дата, привязка к CRM-элементу, файл
- Воронка со стадиями и семантикой (в работе / успех / провал)
- Роботы и бизнес-процессы на каждой стадии
- Карточка элемента с настраиваемыми разделами
- Канбан и список с фильтрацией
- Таймлайн и история изменений
- Права доступа через роли CRM
Документация Битрикс24: Смарт-процессы
Когда стандартного смарт-процесса недостаточно?
Три сценария, при которых нужна разработка:
-
Связи между сущностями. Стандартный смарт-процесс поддерживает привязку к сделке, контакту, компании. Но если нужна связь «многие ко многим» между двумя смарт-процессами (например, «Объект» и «Дефект» — у одного объекта много дефектов, один дефект может относиться к нескольким объектам), придётся создавать промежуточную сущность или реализовать связь через REST-обработчики и кастомные поля типа
crm_multifield. -
Вычисляемые поля. UF-поля не поддерживают формулы. Если поле «Маржинальность» = (Выручка - Себестоимость) / Выручка * 100, его значение нужно пересчитывать обработчиком на событие
onAfterUpdate. Регистрация обработчика:
$eventManager = \Bitrix\Main\EventManager::getInstance(); $eventManager->registerEventHandler( 'crm', 'onAfterCrmDynamicItemUpdate_128', 'local', '\\Local\\Handler', 'recalculateMargin' ); - Кастомная валидация. Стандартная проверка — обязательность поля. Если нужна бизнес-валидация (например, дата окончания не раньше даты начала, сумма позиций равна общей сумме), реализуется через обработчик
onBeforeCrmDynamicItemUpdate, который может отменить сохранение и вернуть ошибку.
Смарт-процесс обрабатывает в 3 раза быстрее, чем аналогичная логика через сделки, что подтверждено на проектах с объёмом свыше 10 000 элементов. При потоке от 200 заявок в месяц проект окупается менее чем за год, экономя до $2.2k–3.2k ежегодно.
Что нужно учесть при проектировании полей и стадий?
Перед созданием смарт-процесса составьте карту полей. Разделяйте:
- Основные поля — отображаются в карточке и списке, участвуют в фильтрации. Оптимально 10–15 полей.
- Служебные поля — используются роботами и обработчиками, скрыты из интерфейса через настройку карточки.
- Архивные поля — данные для истории, не индексируются.
Стадии воронки проектируются по принципу необратимости: элемент движется слева направо, возврат на предыдущую стадию — исключение, а не норма. Каждая стадия должна означать конкретное действие: «На согласовании у юриста», а не «В процессе».
Семантика стадий критична: поля STAGE_SEMANTIC_ID принимают значения P (process), S (success), F (failure). Аналитика CRM строится на этой семантике — воронка конверсий, средний цикл, прогноз. Если семантика не задана, отчёты будут пустыми.
Интеграция через REST API и миграция
Для внешних систем смарт-процессы доступны через REST:
-
crm.type.list— список всех типов сущностей -
crm.item.add?entityTypeId=128— создание элемента -
crm.item.list?entityTypeId=128&filter[STAGE_ID]=DT128_1:NEW— фильтрация по стадии -
crm.item.update— обновление с автоматическим запуском роботов
Формат STAGE_ID для смарт-процессов: DT{entityTypeId}_{categoryId}:{STATUS_CODE}. Это не очевидно и часто вызывает ошибки при интеграции — стадии сделок и смарт-процессов форматируются по-разному.
Если бизнес уже использует сделки не по назначению, миграция в смарт-процесс включает:
- Создание смарт-процесса с аналогичными полями
- Маппинг стадий старой воронки на стадии нового типа
- Пакетный перенос данных через
crm.item.addв цикле (лимит REST — 50 запросов/сек, batch до 50 команд) - Перенастройка роботов и бизнес-процессов
- Переключение интеграций на новый
entityTypeId
| Масштаб | Элементов | Время миграции |
|---|---|---|
| Малый | До 1 000 | 2–4 часа (скрипт + проверка) |
| Средний | 1 000–10 000 | 1 день (пакетный импорт + сверка) |
| Крупный | 10 000+ | 2–3 дня (этапами + параллельная работа двух систем) |
| Возможность | Стандартный смарт-процесс | Кастомная разработка |
|---|---|---|
| Пользовательские поля | Да (все типы) | Да + вычисляемые поля |
| Связи M:N | Нет | Да (через промежуточные сущности) |
| Валидация | Только обязательность | Любая бизнес-логика |
| Интеграция с 1С | Через CommerceML | С гарантией корректного обмена |
Смарт-процессы не поддерживают товарные позиции из коробки в облачной версии — только в коробочной через доработку. Если элементу нужна табличная часть (позиции заказа, перечень работ), реализуйте её через связанные элементы другого смарт-процесса или через кастомное поле типа JSON (хранение в UF_CRM_* строкового типа с сериализацией).
Что входит в работу
При заказе разработки кастомного типа CRM-сущности мы предоставляем:
- Архитектурную схему полей и стадий
- Исходный код обработчиков и REST-интеграций
- Миграцию данных из старых сущностей
- Тестирование в тестовом контуре
- Документацию по API и настройкам
- Гарантию 1 год на все доработки
Получите консультацию и узнайте, как кастомный смарт-процесс решит вашу задачу. Свяжитесь с нами, чтобы оценить проект — мы рассчитаем сроки и стоимость за 1 день. Наш опыт: 5+ лет разработки под Битрикс24, более 50 успешных внедрений.