Уявіть: ви ведете облік об'єктів нерухомості, заявок на ремонт або рекламацій. 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 успішних впроваджень.