Короткий ответ: начните с роботов, если действие привязано к стадии CRM и его легко описать через условие, срок и результат. Рассматривайте бизнес-процесс, когда нужно управлять маршрутом: получать решения сотрудников, хранить промежуточное состояние, обрабатывать отказ и возврат на доработку. Выбор определяется управляемостью сценария, а не количеством блоков на схеме.
Ниже — методика проектирования и проверки. Примеры учебные, это не клиентские кейсы. Доступность инструментов зависит от тарифа, редакции и настроек портала; перед внедрением проверьте нужные действия в своём Битрикс24. Руководство относится к роботам CRM и шаблонам в дизайнере бизнес-процессов.
Чем отличаются роботы и бизнес-процессы
Роботы выполняют действия при попадании элемента CRM на стадию. Для них задают порядок выполнения, время и условия. Например, после перехода сделки на подготовку предложения можно поставить задачу ответственному. Это штатная модель, описанная в руководстве по роботам CRM.
Шаблон бизнес-процесса описывает маршрут действий. В нём есть параметры запуска, изменяемые переменные, константы и права доступа; действия могут выполняться автоматически или сотрудниками. В официальном руководстве по последовательному процессу показаны согласование и ветвление по решению. Такой маршрут полезен, когда результат одного участника определяет работу следующего.
Это не жёсткое разделение «простое — сложное»: несколько последовательных роботов тоже могут решить задачу. Проверяйте другое: сможет ли сопровождающий специалист объяснить, где находится конкретный экземпляр сценария, чего он ждёт и как продолжить работу после сбоя. Если ответ приходится восстанавливать по случайным изменениям стадий, архитектуру стоит упростить.
Матрица выбора автоматизации
| Задача | С чего начать | Что проверить до запуска |
|---|---|---|
| При переходе на стадию назначить следующее действие | Робот с понятным условием | Исполнитель, срок, поведение при повторном входе |
| Последовательно обновить поля и уведомить менеджера | Цепочка роботов с явной очередью | Уведомление использует уже обновлённые данные |
| Согласовать исключение, получить отказ или одобрение | Бизнес-процесс с заданиями и исходами | Кто принимает решение, куда уходит отказ, кто заменяет отсутствующего |
| Долго ждать исполнения с возвратами на доработку | Отдельно описанный маршрут бизнес-процесса | Владелец ожидания, срок реакции, условия завершения |
| Создать заказ во внешней системе | Робот или процесс как инициатор плюс проверенная интеграция | Подтверждение результата, ключ операции, повтор после таймаута |
| Вести исполнение независимо от продажи | Сначала выбрать сущности и связи, затем автоматизацию | Отдельный ответственный, статусы исполнения и связь со сделкой |
Последняя строка — вопрос модели данных. Если продажа и выполнение имеют разные жизненные циклы, начните с карты смарт-процессов и связей. Перенос длинной цепочки в дизайнер сам по себе не исправит смешение этих объектов.
Когда достаточно робота
Запишите сценарий одним предложением: «Когда произошло событие X, при выполнении условий Y сделать Z; успех подтверждается результатом R». Если все части известны и нет отдельного маршрута согласования, настройте минимальную цепочку и проверьте её на тестовом элементе.
- Определите вход. Укажите сущность, воронку, стадию и обязательные исходные поля. Различайте создание карточки и завершение её заполнения интеграцией.
- Задайте зависимости. Действие, использующее результат другого робота, не должно рассчитывать на случайный порядок выполнения.
- Опишите выход. Нужна ссылка на созданную задачу, новое значение поля или подтверждённый результат отправки, а не только отметка о старте.
- Назначьте разбор исключения. Укажите, кто получает информацию об ошибке и что делает, если результата нет.
Настройки очереди, времени и логических условий И/ИЛИ разобраны в официальной инструкции по условиям. Проверяйте отдельно каждую ветвь: непустое поле, пустое поле, подходящее и неподходящее значение. Условие «заполнено» не доказывает корректность данных.
Как разобрать зависший процесс
Сначала сохраните ссылку на элемент, название шаблона, время старта, ожидаемый результат и последнее подтверждённое действие. Не начинайте с массового перезапуска: часть операций уже могла выполниться.
- Найдите конкретный запуск. Сопоставьте его с карточкой и событием старта. Проверьте, нет ли второго экземпляра, который меняет те же данные.
- Отделите ожидание от ошибки. Есть ли активное задание сотруднику, запланированная пауза или ожидание ответа внешнего сервиса? Кто должен выполнить следующий шаг?
- Проверьте входные значения и доступ. Доступен ли исполнитель, существует ли связанный объект, заполнены ли поля именно к моменту проверки условия?
- Соберите журнал. Включите запись для нужного шаблона и воспроизведите проблему на контролируемом примере. Включение сейчас не восстановит отсутствующие прошлые события.
- Выберите способ восстановления. Исправление данных, выполнение ожидаемого задания и запуск нового экземпляра — разные действия. Перед новым запуском перечислите операции, которые нельзя повторять.
Запись журнала отладки включается отдельно для каждого шаблона на семь дней; затем её нужно включить снова. Для истории выполнения заданий используйте «Протокол». Журнал отладки не стоит считать постоянным реестром всех действий: при нескольких срабатываниях робота в элементе там сохраняется информация только о последнем действии.
Изменение шаблона не обновляет уже работающие экземпляры: они продолжают старый сценарий. Также интеграция может заполнить поля позже момента проверки условия. Эти особенности описаны в разборе причин сбоев Битрикс24. Поэтому после исправления проверяйте новый запуск отдельно от старого; задержку выбирайте по фактическому порядку поступления данных.
Как предотвратить повторное действие
Цель — контролировать результат при повторном событии. Возврат на стадию может быть нормальной частью работы; запретить его ради защиты от дублей означает изменить бизнес-процесс. Сначала решите, что должно выполняться один раз на сделку, один раз на версию документа или при каждом новом согласовании.
Учебный пример: для подготовки предложения требуется одна задача на конкретную версию предложения. В проектируемом сценарии сохраняют версию и ID созданной задачи. При повторном событии сначала проверяют существующий результат; новую задачу создают только по правилам новой версии или согласованного восстановления. Названия служебных полей и сама схема — проектное решение, а не готовая настройка «без дублей».
Простой флаг «выполнено» полезен для последовательного сценария, но не гарантирует защиту от двух одновременных запусков: оба могут прочитать пустое значение до его изменения. Если операция внешняя или критична к дублям, нужна проверка уникальности операции в обработчике. После таймаута сначала выясняют, создан ли объект на принимающей стороне. Подробности вынесены в разбор идемпотентности интеграций.
Проверьте все входы в один сценарий: автоматический старт, ручной запуск, роботы и интеграция. Для каждого оставленного входа должно быть объяснение. Не запускайте одинаковую операцию несколькими независимыми механизмами без общего правила учёта результата.
Что записать в паспорт сценария
Храните описание рядом с регламентом изменений. Оно должно позволять другому специалисту восстановить замысел без перебора всех настроек.
- Название, цель, владелец и дата версии сценария.
- Сущность, условия запуска, обязательные данные и разрешённые способы ручного старта.
- Последовательность действий, зависимости, ожидания и ответственные за них.
- Какие поля читаются и изменяются; какие объекты создаются и где сохраняются их ID.
- Правило повтора, признаки успешного результата и маршрут обработки ошибки.
- Где искать журнал, как остановить сценарий и что проверить перед восстановлением.
- Тестовые примеры, ожидаемые результаты и ссылки на подтверждения проверки.
При изменении отдельно решите судьбу уже запущенных экземпляров. В журнале изменений укажите, какие остаются на прежней версии и какие требуют контролируемого завершения. Удаление блока из шаблона не является доказательством остановки старого запуска.
Как проверить результат перед запуском
Для сделок используйте отладчик роботов: он показывает действия, условия и ошибки. Этот инструмент доступен именно в сделках; не переносите его возможности автоматически на остальные сущности. Тестируйте с контролируемыми адресатами, чтобы проверочные сообщения не уходили клиентам.
- Обычный вход: нужный результат создан, исполнитель и срок верны.
- Неполные данные: сценарий не выполняет неверную операцию; причина понятна ответственному.
- Возврат на стадию: число задач и отправок соответствует правилу повтора.
- Отказ и доработка: маршрут завершается или возвращается в предусмотренную точку.
- Отсутствующий участник: определён способ передачи задания или эскалации.
- Ошибка внешней системы: повтор не создаёт второй результат после успешного, но неподтверждённого первого запроса.
- Новая версия шаблона: отдельно проверены новый экземпляр и судьба старого.
Приёмка завершена, когда для каждого применимого теста есть фактический результат и ссылка на задачу, элемент или запись журнала. Если исключения остаются необъяснёнными, расширять автоматизацию рано.
Для действующего портала следующий шаг — сопровождение Битрикс24 с ревизией сценариев и приоритетов исправления. Если нужен новый маршрут, на странице автоматизации продаж описан проектный формат: от текущего процесса и контрольных примеров до критериев приёмки.