При автоматизации CRM в Битрикс24 часто требуется поставить короткую паузу в бизнес-процессе — не на часы или дни, а буквально на несколько секунд. Например, чтобы дать системе зафиксировать изменения, корректно отработать триггеры и только после этого перевести сделку на следующую стадию. Для этого администраторы используют приложение «Своя короткая пауза в роботах и БП», которое позволяет реализовать задержки, недоступные стандартными средствами.
В чем возникла проблема
После настройки бизнес-процесса пауза отрабатывала, но следующее действие (смена стадии) не выполнялось. В журнале бизнес-процессов было видно, что процесс зависает на этапе ожидания, несмотря на корректно заданное количество секунд. Внешне настройки выглядели правильными, и стандартная диагностика не указывала на очевидную ошибку.
Ограничения стандартных инструментов
Штатные механизмы ожидания в Битрикс24 имеют минимальные пороги (минуты и часы) и не рассчитаны на кратковременные задержки. Поэтому для сценариев «пауза → действие» администраторы вынуждены использовать сторонние активити. При этом важно учитывать особенности выполнения бизнес-процессов в облаке и требования к авторизации роботов.
Ключевое решение: от чьего имени запускается робот
Первый и самый критичный нюанс — робот должен запускаться от имени действующего пользователя.
В данном кейсе бизнес-процесс запускался от имени пользователя с ID = 1, который оказался уволенным. В результате приложение физически не могло выполнить действие и возвращало ошибку авторизации, из-за чего процесс зависал на паузе.
После смены пользователя на актуального сотрудника с действующими правами бизнес-процесс начал корректно отрабатывать: пауза завершалась, стадия сделки менялась, процесс доходил до конца.
Второй важный момент: период ожидания ответа приложения
Для подстраховки в настройках робота всегда рекомендуется устанавливать период ожидания ответа приложения — 10 минут.
Это не значит, что пауза будет длиться 10 минут. Этот параметр выполняет другую функцию: если на сервере, где работает приложение, возникнет временный сбой или задержка, бизнес-процесс не зависнет навсегда, а корректно продолжит выполнение после тайм-аута.
Такой подход особенно важен для облачных порталов, где администратор не контролирует инфраструктуру и должен закладывать защиту от нестабильных внешних факторов.
Пример логики бизнес-процесса
Логика выглядит следующим образом:
сначала в переменную записывается нужная длительность задержки → затем используется активити короткой паузы → после ее завершения выполняется действие (например, смена стадии сделки). Критично, чтобы весь процесс выполнялся от имени действующего пользователя и имел резерв по времени ожидания ответа.
Результат
После корректировки двух параметров — пользователя запуска и периода ожидания — бизнес-процесс стал стабильно работать. Пауза отрабатывается за секунды, стадия меняется сразу после нее, а риск зависаний полностью устранен даже при временных сбоях.
Вывод
Если вы используете короткие паузы в бизнес-процессах Битрикс24, всегда проверяйте два момента:
робот должен запускаться от имени активного пользователя, а период ожидания ответа приложения — быть не менее 10 минут. Эти настройки неочевидны, но именно они чаще всего становятся причиной «зависших» процессов, а не само приложение или логика автоматизации.
