Отладка и логи сценариев

Даже аккуратно собранный сценарий иногда ведёт себя не так, как задумано: не срабатывает, срабатывает лишний раз или зацикливается. Отладка — это умение быстро найти причину по истории заказа и логам. Разберём системный подход к диагностике.

История заказа как основной источник

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

По истории можно восстановить всю цепочку событий:

• момент создания заказа и его исходный статус;
• каждую смену статуса с указанием источника (менеджер или триггер);
• изменения полей и назначение менеджеров;
• отправленные уведомления.

Сценарий не срабатывает: чек-лист

Самая частая жалоба — «правило не работает». Проверяйте по порядку:

1. Триггер активен? Деактивированное правило не запускается вообще;
2. Верное событие? «Заказ создан» не сработает на смене статуса вручную;
3. Условия выполнимы? Логика И с противоречивыми проверками никогда не даст «истину»;
4. Заказ реально подходит? Сверьте фактические поля заказа с условиями правила;
5. Нет более раннего триггера, который уже увёл заказ из нужного статуса.

Зацикливание и лишние срабатывания

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

Универсальное правило профилактики — всегда проверять исходное состояние в условии, чтобы действие не могло повторно активировать своё же событие.

Логи и мониторинг

Помимо истории заказа, для диагностики полезны системные журналы:

• Лог уведомлений — доставлены ли SMS и email, какой был текст и статус отправки;
• Лог интеграций — обмен со службами доставки, платёжными системами, 1С;
• История срабатываний триггеров — где видно, какое правило и когда выполнилось.

При проблемах с уведомлениями сначала смотрят именно лог отправки: часто «сценарий не работает» на деле означает «SMS не доставлена из-за баланса или неверного номера», а само правило отработало верно.

Отладка webhook и интеграций

Когда сценарий вызывает внешний сервис, точек отказа больше. Диагностика webhook-действий:

1. Проверьте, что RetailCRM отправил запрос — по логу интеграций;
2. Убедитесь, что ваш сервис ответил кодом 200 OK, а не ошибкой;
3. Сверьте тело запроса — приходят ли ожидаемые поля заказа;
4. Проверьте права API-ключа, которым внешний сервис пишет обратно в CRM.

Профилактика проблем

Большинство инцидентов дешевле предотвратить, чем отлаживать. Практики, которые экономят время:

• Реестр сценариев — таблица со всеми правилами: событие, условия, действия, зачем;
• Понятные названия триггеров вместо «Триггер 7» — сразу видно назначение;
• Тест перед запуском на «должен» и «не должен сработать» заказах;
• Изменения по одному — правьте по одному правилу за раз, чтобы понимать причину при поломке;
• Ревизия раз в квартал — отключайте неактуальные правила.

Итог

Отладка сценариев строится на истории заказа и системных логах: они показывают, сработал триггер или нет и на каком шаге. При несрабатывании проверяют активность, событие и условия; при зацикливании — добавляют проверку исходного состояния; при сбоях интеграций — читают логи webhook и права API. Профилактика через реестр правил и тестирование экономит массу времени.

Если автоматизация в вашей RetailCRM ведёт себя непредсказуемо, специалисты B2Bsite проведут аудит сценариев, найдут конфликтующие и зацикленные правила и приведут логику в порядок — в рамках поддержки и развития системы.