Проектирование логики бизнес-процессов Битрикс24

Проектирование логики бизнес-процессов Битрикс24

Бизнес-процессы в Битрикс24 — одна из тех функций, которые при грамотном применении экономят часы ежедневной ручной работы, а при непродуманном внедрении создают хаос: зависшие экземпляры, уведомления, которые никуда не доходят, и задачи, которые «провалились» на неопределённый шаг без индикации причины.

За несколько лет проектирования БП разного масштаба у нас сложилось чёткое понимание: большинство проблем появляются не на этапе реализации в визуальном дизайнере, а на этапе постановки задачи — когда логика процесса не зафиксирована формально до начала «клика мышкой».

Архитектура БП в Битрикс24

Движок бизнес-процессов в Битрикс24 основан на модуле bizproc. Процесс описывается как граф активностей (CBPActivity) с переходами между ними. Каждый экземпляр процесса хранится в таблицах b_bp_workflow_instance, b_bp_workflow_state, b_bp_task — именно туда нужно смотреть при диагностике зависших процессов.

Активности делятся на:

• Системные — задержка, условие, параллельная активность, цикл.
• Действия — отправка уведомления, создание задачи, изменение поля сущности, вызов REST-метода.
• Пользовательские действия (UDA) — кастомные активности, написанные на PHP и зарегистрированные через CBPActivity::RegisterActivity().

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

Процесс проектирования

Шаг 1. Формализация процесса в BPMN (или упрощённой нотации).

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

Именно исключительные пути — главный источник проблем в реализованных БП. В дизайнере их забывают, и процесс зависает на ожидании без каких-либо сигналов.

Шаг 2. Инвентаризация переменных.

В Битрикс24 у каждого процесса есть: переменные процесса (хранятся только в рамках экземпляра), параметры процесса (входящие значения при старте) и константы. Кроме того, через Document доступны поля самой сущности.

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

Шаг 3. Определение триггеров.

Процессы запускаются вручную, по событию (изменение поля, смена стадии, добавление сущности) или по расписанию (через агенты в модуле bizproc). От типа триггера зависит архитектура: если процесс стартует по смене стадии сделки, нужно предусмотреть защиту от повторного запуска при возврате на ту же стадию.

Шаг 4. Проектирование уведомлений.

Уведомления в БП настраиваются через активность «Уведомление» с адресацией по роли (ответственный, автор, конкретный пользователь, группа). Типичная ошибка — уведомление уходит «ответственному», но в момент выполнения шага поле «Ответственный» ещё не заполнено. Нужно явно прописывать цепочку адресации для каждого шага.

Кейс: процесс согласования договора

Клиент — производственная компания, 80 пользователей Битрикс24. Задача: автоматизировать согласование договора через CRM. Договор прикреплён к сделке как пользовательское поле типа «Файл». Участники согласования: юрист, финансовый директор, генеральный директор — последовательно.

Исходная попытка клиента: три последовательных задания в БП, каждое — «Утвердить/Отклонить». Проблема: при отклонении на любом шаге процесс просто завершался без возможности доработки и повторной подачи.

Переработанный вариант включал:

• Цикл «подача → согласование» с возможностью возврата на доработку на любом этапе с комментарием
• Таймер эскалации: если юрист не ответил за 2 рабочих дня — уведомление руководителю
• Параллельное уведомление инициатору о текущем статусе на каждом шаге
• Запись итогового статуса согласования в пользовательское поле сделки для отчётности
• Автоматическое создание задачи на юрисконсульта с вложением файла договора

Реализация заняла 8 рабочих дней с учётом тестирования на тестовом окружении и переноса на продакшн.

Ограничения и подводные камни

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

Производительность. Тяжёлые БП с большим количеством параллельных веток и REST-вызовами могут создавать нагрузку на cron. Если агент CBPSchedulerService::OnAgent запускается каждую минуту, а активных экземпляров несколько сотен — это заметно. Проектируем с учётом нагрузки.

REST-активности. Вызов внешних систем через REST из БП делается через активность «Исходящий вебхук» или через кастомную UDA. Нужно предусмотреть обработку ошибок: если внешний сервис недоступен, процесс не должен зависать навсегда.

Сроки

Проектирование одного линейного процесса (5–8 шагов, без параллельных веток) — 2–4 дня. Сложный процесс с ветвлением, эскалациями, интеграциями — 1–3 недели. В услугу входят: блок-схема согласованного процесса, реализация в дизайнере БП, документация переменных, тестирование и передача.