Бизнес-процессы в Битрикс24: как собрать свой сценарий

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

Что будем автоматизировать

Менеджер вручную запускает бизнес-процесс из карточки сделки. Сценарий проверяет сумму и, если она достигает заданного порога, создаёт задачу согласующему, отправляет ему уведомление и ждёт решения. После одобрения сделка получает следующий статус, после отказа менеджер видит причину и может внести изменения.

Материал рассчитан на облачный Битрикс24. У сервиса нет единого номера версии для всех порталов: интерфейс, доступность бизнес-процессов и отдельные действия зависят от тарифа и текущих обновлений. В коробочной редакции Битрикс24 24.x названия разделов и набор настроек могут отличаться.

Хороший бизнес-процесс не заменяет правила компании. Он превращает уже согласованный порядок работы в проверяемую последовательность действий.

Что нужно определить до настройки

• какая сущность запускает сценарий — в примере это сделка;
• кто запускает процесс и кто принимает решение;
• какое поле проверяется — сумма сделки;
• что считается одобрением, отказом и просрочкой;
• какие данные должны попасть в уведомление и задачу.

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

Робот или бизнес-процесс

Сначала выберите правильный механизм. Если действие должно сработать автоматически после изменения поля, чаще всего хватит робота. Если в сценарии есть ручное решение, несколько веток, ожидание или возврат на доработку, используйте бизнес-процесс.

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

Как собрать свой сценарий

1. Создайте шаблон в нужной сущности

Откройте CRM и перейдите к настройкам бизнес-процессов той сущности, где будет работать сценарий. Для примера это сделки. Создайте новый шаблон и назовите его понятно: «Согласование сделки от 100 000 рублей».

Не называйте шаблон «Процесс 1» или «Новый БП». Через несколько месяцев в списке появятся десятки похожих элементов, и владельцу портала будет трудно понять, какой из них используется.

Проверка: шаблон отображается в списке бизнес-процессов именно у сделок, а не у задач или элементов другой CRM-сущности.

2. Настройте запуск

Для первого варианта выберите ручной запуск из карточки сделки. Это безопаснее автоматического старта: менеджер может сначала заполнить сумму, клиента и описание, а затем отправить сделку на согласование.

Автоматический запуск после создания сделки удобен, если правило действует всегда. Но он создаёт лишние процессы для тестовых, ошибочных и небольших сделок. В рабочей CRM это быстро превращается в очередь ненужных задач.

Проверка: откройте тестовую сделку и убедитесь, что команда запуска бизнес-процесса доступна пользователю с ролью менеджера.

3. Добавьте проверку суммы

Первым логическим блоком разместите условие по полю суммы сделки. В одной ветке будет значение от 100 000 рублей и выше, во второй — меньшая сумма.

Для малой сделки можно сразу изменить статус или завершить процесс сообщением «Согласование не требуется». Для крупной — продолжить маршрут к руководителю.

Порог лучше хранить в названии шаблона и описании условия. Если лимит изменится, администратор быстрее найдёт нужную настройку и не будет искать число среди десятков блоков.

Проверка: запустите процесс на двух тестовых сделках: со значением ниже порога и со значением выше него. Они должны попасть в разные ветки.

4. Назначьте согласующего

Добавьте действие, которое создаёт задачу или запрос на утверждение. Ответственного не стоит зашивать в процесс, если руководитель может меняться. Используйте сотрудника, указанного в поле сделки, ответственное лицо направления или заранее настроенную роль, если такая возможность доступна в вашем интерфейсе.

В текст задачи включите четыре элемента: название сделки, сумму, ссылку на карточку и срок ответа. Не копируйте в задачу все поля CRM — длинный текст снижает шанс, что согласующий быстро найдёт главное.

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

5. Разведите одобрение и отказ

Добавьте действие, в котором сотрудник выбирает результат: одобрить или отказать. Для отказа сделайте обязательным поле с причиной, если конструктор и ваш тариф позволяют это настроить. Если отдельного обязательного поля нет, зафиксируйте требование в тексте задания и проверьте его на тестах.

Ветка одобрения может изменить статус сделки на «Согласовано» и уведомить менеджера. Ветка отказа должна записать причину, вернуть сделку на статус доработки и уведомить ответственного.

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

6. Добавьте ожидание и защиту от зависания

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

Не завершайте процесс молча, если согласующий ничего не сделал. Отправьте напоминание, создайте задачу заместителю или уведомите администратора. Конкретный вариант зависит от регламента компании и возможностей тарифа.

Проверка: создайте тестовый запуск без ответа и убедитесь, что через установленный срок появляется напоминание или другой предусмотренный сигнал.

Что обычно ломается

• Процесс не виден менеджеру. Проверьте права на запуск бизнес-процессов и доступ к самой сущности. Также убедитесь, что шаблон опубликован и привязан к сделкам.
• Сумма не попадает в нужную ветку. Проверьте тип поля, валюту и условие сравнения. Отдельно протестируйте пустое значение: оно может обрабатываться не так, как ноль.
• Задача создаётся не тому сотруднику. Посмотрите, откуда процесс берёт ответственного: из сделки, подразделения или фиксированного пользователя. После увольнения или перевода сотрудника такой маршрут часто становится неактуальным.
• После отказа процесс запускается заново бесконечно. Проверьте роботов и автоматические триггеры на статусе доработки. В условии повторного запуска должен быть явный ограничитель.
• Менеджер видит результат, но не причину. Передавайте причину отказа в комментарий, отдельное поле или историю процесса. Уведомление без контекста быстро теряет ценность.

Где подход ломается

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

Есть и другие ограничения:

• названия действий и расположение настроек меняются вместе с интерфейсом и тарифом;
• права пользователя могут отличаться от прав автора шаблона;
• длинный процесс сложно восстановить, если сотрудник удалён или его роль изменилась;
• бизнес-процесс не заменяет полноценную интеграцию с бухгалтерской или ERP-системой.

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

Что настроить дальше

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

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

Через неделю после запуска сравните историю процессов с регламентом. Всё, что сотрудники обходят вручную, — кандидат на изменение сценария, а не повод добавлять ещё один робот.