При ошибке ИИ-сценария в n8n сначала выясните, какое действие действительно завершилось во внешней системе. Затем выбирайте между повтором запроса, исправлением данных и ручным восстановлением. Статус Success описывает выполнение workflow — цепочки узлов автоматизации; наличие нужной заявки в CRM следует проверять отдельно.
FAQ предназначен для владельца процесса и специалиста, сопровождающего маршрут «обращение → ИИ-классификация → CRM → уведомление». Здесь разбираем ошибки, повторные выполнения и восстановление. Установка n8n, выбор модели и настройка конкретной CRM требуют отдельных инструкций.
Материал AIrassvet подготовлен с использованием ИИ 20 октября 2026 года по актуальной официальной документации. Описанные настройки — документированный порядок, а не отчёт об испытании: редакция не запускала этот workflow, модель или CRM. Условная заявка REQ-1042 нужна только для примеров. В конце есть раздел об услугах издателя; партнёрских ссылок и спонсорских рекомендаций нет.
Иллюстрация показывает условный маршрут обращения, а не интерфейс n8n или реальную установку клиента.
Содержание:
- Почему Success не подтверждает результат?
- Где искать место сбоя?
- Чем Retry On Fail отличается от Retry execution?
- Что делать при ошибке 429?
- Почему не запускается Error Trigger?
- Что передавать в уведомление об ошибке?
- Как повторить выполнение после исправления?
- Защитит ли Remove Duplicates от повторной записи?
- Что делать, если ИИ ответил, но ответ непригоден?
- Как восстановить маршрут с AIrassvet?
- С чего начать разбор текущего сбоя?
Почему Success не подтверждает результат?
Потому что техническое завершение цепочки и выполненная задача бизнеса — разные условия. Проверьте, не разрешено ли узлу продолжать выполнение при ошибке. В Settings → On Error документация различает Stop Workflow, Continue и Continue (using error output): остановку, продолжение с последними корректными данными и продолжение с передачей сведений об ошибке. Настройки узлов n8n.
Для условной REQ-1042 успех процесса можно определить так: в CRM существует обращение с этим внешним идентификатором, текст сохранён, категория допустима, ответственный назначен. Это предлагаемое бизнес-правило, которое команда должна реализовать и проверить в своей интеграции.
Если ошибка передаётся по отдельной ветке, убедитесь, что ветка заканчивается понятным исходом: задача на ручной разбор действительно создана либо выполнение остановлено. Одно продолжение цепочки не подтверждает, что клиентское обращение принято в работу.
Где искать место сбоя?
Откройте конкретное выполнение и сопоставьте вход, выход проблемного узла и состояние внешней системы. В Overview → Executions можно отфильтровать workflow, статус и время запуска. Важно найти именно выполнение нужной заявки, а не похожую ошибку другого обращения. Просмотр выполнений.
Пример разбора: ИИ-классификация вернула категорию, узел CRM сообщил о тайм-ауте, уведомление не отправлено. Пока неизвестно, создала ли CRM запись до потери ответа. Найдите REQ-1042 средствами CRM или её API; зафиксируйте найденный идентификатор. Только после этой сверки решайте, нужна ли новая запись.
Чтобы данные были доступны для следующих разборов, проверьте Workflow settings → Save failed production executions. Для случаев «технически успешно, фактически неполно» полезна также осознанная настройка Save successful production executions. Состав сохраняемых данных согласуйте с правилами компании: история может содержать тексты обращений. Сохранение выполнений.
Чем Retry On Fail отличается от Retry execution?
Retry On Fail относится к повтору узла при ошибке; Retry execution — к повторному выполнению workflow с данными прошлого запуска. Эти механизмы решают разные задачи и не подтверждают безопасность повторной записи во внешнюю систему. Документированный порядок включения Retry On Fail: открыть узел → Settings → включить переключатель → задать параметры повторов. Повторы запросов в n8n.
| Ситуация | Предлагаемое решение | Что выяснить перед действием |
|---|---|---|
| Временный сбой чтения данных | Ограниченный повтор узла | Допустимы ли повторные запросы и их стоимость |
| Неверное обязательное поле | Исправление входа | Какое значение ожидает принимающая система |
| Тайм-аут при создании обращения | Сверка с CRM | Создан ли объект, несмотря на отсутствие ответа |
| Ошибка настройки workflow | Исправление и выбранный вариант Retry execution | Какие внешние действия могут выполниться повторно |
Таблица — рекомендации по проектированию, а не универсальная политика n8n. Для записи в CRM безопасность определяется ещё и возможностями её API. Не используйте повтор как средство исправления неизвестного результата операции.
Что делать при ошибке 429?
Уменьшить частоту запросов в соответствии с лимитами конкретного сервиса и ограничить повторы. В документации n8n код 429 связан с превышением допустимой частоты. Для управления потоком описаны Retry On Fail с паузой и сочетание Loop Over Items с Wait. Обработка rate limits.
Не переносите произвольную паузу из чужого примера на свой API. Сначала выясните его ограничения и правила повторов, затем настройте интервалы и допустимое число попыток в своей версии узла. Если несколько выполнений обращаются к одному сервису, учитывайте их общий поток.
Признак исправления для предлагаемой проверки: разрешённая тестовая серия обрабатывается без бесконтрольных повторов; исчерпание попыток приводит к явному исходу для сотрудника. Это критерий будущего испытания, а не измеренный здесь результат. Увеличение числа параллельных запросов само по себе не устраняет ограничение провайдера.
Почему не запускается Error Trigger?
Частая причина — попытка проверить его ручным запуском основного workflow. Официальная документация прямо указывает: Error Trigger реагирует на ошибку автоматического выполнения; ручной запуск для такой проверки не подходит. Сам workflow с Error Trigger не требуется публиковать. Условия работы Error Trigger.
Документированный порядок подключения: создайте отдельный workflow с первым узлом Error Trigger, сохраните его, затем выберите его в настройках основного workflow в поле Error workflow и сохраните основной. При необработанном сбое будет вызван выбранный обработчик. Подключение error workflow.
Для проверки используйте отдельную тестовую копию без реальных отправок и записей. Запустите её предусмотренным автоматическим триггером и вызовите контролируемую ошибку. Если ветка Continue поглотила ошибку, сам факт неполученного бизнес-результата ещё не означает, что workflow завершился с ошибкой и вызовет обработчик.
Что передавать в уведомление об ошибке?
Достаточно контекста, чтобы сотрудник нашёл выполнение и понял следующий шаг. Предлагаемый состав сообщения: название процесса, доступный идентификатор выполнения, узел сбоя, короткое описание ошибки и ссылка на выполнение. Идентификатор исходной заявки добавляйте только если вы отдельно обеспечили его передачу или поиск.
Error Trigger документирует поля workflow.name, execution.error.message, execution.lastNodeExecuted и другие сведения. Но execution.id и execution.url зависят от сохранения выполнения и отсутствуют при некоторых сбоях триггера; execution.retryOf появляется только у повторного выполнения. Структура ошибки триггера также отличается от ошибки последующих узлов. Данные обработчика ошибок.
Пример содержания, которое стоит собрать из доступных данных: «Маршрут обращения остановился при записи в CRM. Результат записи неизвестен. Перед повтором найти обращение по внешнему ID». Это редакционный образец сообщения, не готовое выражение n8n. Не пересылайте полный текст клиента и секреты доступа в общий канал диагностики.
Как повторить выполнение после исправления?
Сначала выберите нужную версию схемы и проверьте последствия повторных действий. В Executions → Retry execution есть два варианта: Retry with currently saved workflow использует текущий сохранённый workflow и данные прошлого выполнения; Retry with original workflow — исходный workflow и те же прежние данные. Варианты повторного выполнения.
Если исправлена настройка узла, возврат к исходной схеме может вернуть ту же ошибку. Если изменились данные в CRM, старый вход тоже не обязательно отражает текущее состояние бизнеса. Перед повтором отдельно определите уже выполненные записи и отправки; не считайте кнопку Retry гарантией продолжения ровно с безопасного места.
Для отладки документация предлагает Debug in editor для неуспешного выполнения и Copy to editor для успешного. Данные переносятся в текущий workflow и закрепляются в первом узле. Доступность функции зависит от редакции; для self-hosted перечислены Registered Community, Business и Enterprise. Отладка прошлых выполнений.
Перед экспериментом переключите внешние действия на тестовые объекты. После него подтвердите результат непосредственно в принимающей системе.
Защитит ли Remove Duplicates от повторной записи?
Узел помогает отсеивать повторные входные элементы, но его результат нельзя приравнять к подтверждённой записи в CRM. Документация различает удаление повторов в текущем входе и сравнение с предыдущими выполнениями. Для режима предыдущих выполнений важны выбранное поле сравнения, область истории и её размер. Возможности Remove Duplicates.
Условный внешний ID REQ-1042 должен обозначать исходное обращение. Если при каждом повторе генерировать новый ID, одинаковая заявка перестанет выглядеть одинаковой. Но и совпадение ID во входе ещё не отвечает на вопрос, удалось ли завершить запись после фильтра.
Разделите два решения: «это событие уже встречалось» и «его бизнес-действие завершено». Для повторной записи выясните, поддерживает ли ваша CRM уникальный внешний ключ, поиск или идемпотентный запрос — запрос, повтор которого не создаёт дополнительный результат. Такой контракт требует документации конкретной CRM; универсального готового решения здесь нет.
Что делать, если ИИ ответил, но ответ непригоден?
Обрабатывать это как отдельное условие процесса. Успешный вызов модели может вернуть неподходящую категорию или пропустить существенный факт. Для примера с обращениями задайте разрешённые категории и предусмотрите маршрут «нужно уточнение», когда текст не позволяет выбрать одну из них.
Предлагаемый порядок: сохранить исходное обращение, проверить обязательные поля и допустимые значения, затем направить результат в CRM либо сотруднику. Не подставляйте выдуманную категорию ради прохождения проверки. Подробнее о независимой проверке полей — в инструкции по структурированному выводу Ollama; она показывает другой технический стек, но объясняет границу между корректным форматом и верным содержанием.
Если непригодный ответ должен завершать выполнение с ошибкой, n8n документирует узел Stop And Error, который позволяет намеренно остановить выполнение и задействовать настроенный error workflow. Принудительная ошибка. Выбор между остановкой и ручным разбором зависит от вашего процесса: главное, чтобы обращение имело явный дальнейший маршрут.
Как восстановить маршрут с AIrassvet?
Если сбой повторяется на стыке модели и бизнес-системы, полезно разобрать сам процесс. В рамках направлений AIrassvet задача может включать описание маршрута обращения и исключений, подготовку правил проверки данных, интеграцию и тестирование перехода к записи или ручному разбору. Это направления работ издателя, а не гарантия поддержки любой версии n8n или конкретной CRM.
Первый шаг — выбрать один проблемный процесс, его текущее время и частоту сбоев, источники данных, ограничения и критерий восстановления. Подготовьте обезличенный пример входа и сведения о том, какое действие уже произошло во внешней системе. Обсудить задачу.
С чего начать разбор текущего сбоя?
Найдите одно выполнение и исходное обращение. Установите, что сохранилось в CRM, затем определите причину: временная ошибка запроса, неверные данные, непригодный ответ ИИ или ошибка схемы. Выберите ограниченный повтор, исправление либо ручное восстановление и подтвердите итог в принимающей системе.
Для общего выбора платформы и объёма внедрения используйте обзор n8n для бизнеса. Для текущего инцидента главный вопрос конкретнее: какое действие осталось незавершённым и как выполнить его, учитывая уже полученный результат.
