Условный пример: после смены стадии менеджер получает две одинаковые задачи. Он удаляет лишнюю, а завтра история повторяется. Робот выглядит очень трудолюбивым, но дополнительная активность команде не помогает.
Не начинайте с удаления всех роботов. Сначала выясните, одно действие выполнилось повторно или похожие действия запустили разные участники: робот, бизнес-процесс, интеграция либо сотрудник.
Восстановите цепочку событий
Возьмите одну обезличенную запись и выпишите время переходов, изменения полей и появление задач. Сопоставьте историю карточки с доступными журналами автоматизации и интеграции.
Робот выполняет настроенное действие, а триггер реагирует на событие и может переместить элемент на другую стадию. В официальной инструкции по триггерам описано и разрешение переходить на предыдущий статус. Проверьте эту настройку там, где она используется.
Возврат на стадию может быть частью нормальной работы. Вопрос в том, какие действия при таком возврате должны повторяться, а какие — нет.
Ищите замкнутый маршрут
Условный сценарий ошибки: правило меняет поле, другое реагирует на изменение и возвращает карточку назад, а следующий переход снова запускает исходное действие. Возможна и другая причина: внешняя система повторно передаёт одно событие.
Нарисуйте последовательность фактических событий. Не объявляйте любое повторение «петлёй»: два разных правила могут независимо создавать похожие задачи. Исправление здесь будет другим.
Определите правило повторения
Для каждого действия решите: оно требуется при каждом входе на стадию или один раз для конкретного события? Отправку уведомления, создание поручения и обновление поля нельзя считать одинаковыми по последствиям.
Если нужен признак выполненного действия, согласуйте, где он хранится, кто может его менять и когда допустим сброс. Одна галочка без этих правил быстро превращается в ещё одну загадку. Для внешнего обмена отдельно проверяют идентификаторы событий и защиту от дублей.
Проверяйте без контакта с настоящим клиентом
Используйте тестовые записи и отключённые внешние отправки. Не считайте слово «отладка» гарантией изоляции: у Битрикс24 есть режим отладки на реальной сделке. Проверяйте, какие действия действительно выполнятся. Доступность инструментов зависит от вашего тарифа и конфигурации.
Пройдите обычный маршрут, возврат на стадию и повтор того же события. Посчитайте созданные задачи и сообщения. После исправления сохраните описание ожидаемого поведения для следующего изменения автоматизации.
Для команды в Кыргызстане согласуйте время проверки и часовой пояс журналов. Не сравнивайте отметки разных систем, пока не ясно, по каким часам они записаны.
QQDev работает с автоматизацией Битрикс24. На странице внедрения можно обсудить повторные действия: покажите одну обезличенную цепочку, ожидаемое количество задач и фактический результат. Это поможет найти причину точнее, чем просьба «сделать робота менее активным».