n8n готовится к версии 3.0: как обновить автоматизацию и не остановить передачу заявок в CRM

Посетитель отправил форму, сайт показал «Спасибо», рекламная система засчитала конверсию. Но в CRM обращение не появилось. Если передачей данных занимается n8n, после неудачного обновления может возникнуть именно такая ситуация: сайт работает, реклама приводит людей, а менеджеры не получают заявки.

Команда AdminVPS разбирает, как подготовиться к n8n 3.0: проверить совместимость, сохранить обращения на время работ и подтвердить их доставку в CRM.

Что известно о n8n 3.0

На момент подготовки материала ветка 3.x находится в раннем доступе. Разработчики объявили о выходе бета-версии 3.0.0 27 октября, а стабильный выпуск запланировали на начало декабря. Это план, поэтому перед обновлением следует заново проверить статус релиза.

Версия 3.0 сосредоточена на надёжности, безопасности и внутренних изменениях. Устаревшие компоненты удаляют, некоторые сценарии будут работать иначе. Существующие интеграции придётся проверить, даже если новые возможности пока не нужны.

При самостоятельном размещении виртуальный сервер позволяет выбирать время обновления и разворачивать среду для проверки. Порядок миграции, сохранность данных и тестирование связки с CRM организует команда проекта.

Срочно переводить рабочую систему на предварительный выпуск не требуется. По объявленному плану, ветка 2.x будет получать исправления безопасности и критических ошибок ещё 12 месяцев после стабильного релиза 3.x. Если используется 1.x, сначала предстоит переход на 2.x; прямого пути на 3.x разработчики не предусматривают. Поддержка 1.x завершается 31 декабря 2026 года.

Какие изменения могут затронуть заявки

Сценарии автоматизации в n8n называются workflow и состоят из отдельных узлов. В 3.0 удаляются устаревшие Function и Function Item, Cron и Interval, а также ряд других узлов. Для них предусмотрены современные замены: в приведённых примерах это Code и Schedule Trigger. Если в опубликованном сценарии остаётся удалённый узел, такой сценарий не активируется при запуске n8n 3.0. Его триггеры перестанут срабатывать.

Есть и изменения без полного отказа сценария. Например, по-другому работает настройка Always Output Data у узлов с несколькими выходами, включая If и Switch. Если маршрутизация заявок зависит от неё, нужно проверить, какие ветки выполняются после перехода. Успешное завершение workflow ещё не доказывает, что обращение назначено правильному менеджеру.

Отдельная задача касается способа установки. Для самостоятельного размещения n8n 3.0 требуется развёртывание на основе Docker; запуск через npm или npx больше не поддерживается. Если система установлена старым способом, перенос окружения нужно подготовить заранее. Простая установка нового экземпляра не переносит в него рабочие данные и настройки.

Начните с маршрута заявки и отчёта совместимости

Составьте карту источников обращений, обрабатывающих их сценариев и ответственных за проверку. Форма сайта и заявка из мессенджера могут попадать в CRM разными путями. Каждый маршрут нужно проверить отдельно; начать стоит с тех, которые принимают оплаченный рекламный трафик.

Затем администратору нужно открыть Settings > Migration Report. Отчёт доступен начиная с n8n 2.39; разработчики рекомендуют использовать актуальную 2.x, где находится свежая версия инструмента. Обновление внутри 2.x тоже следует выполнять с резервной копией и проверкой изменений.

В отчёте важны обе вкладки: Workflow issues показывает проблемы сценариев, Instance issues — настройки всего экземпляра. Вторую видят владелец и администраторы. Если проверку проводит только маркетолог с ограниченными правами, часть замечаний может остаться вне его поля зрения.

Для некоторых узлов доступно автоматическое исправление. Его результат сохраняется как новая версия сценария: опубликованная продолжает работать до публикации изменений. Это удобный способ подготовить замену, но после неё всё равно нужно сравнить результат обработки данных. Пустой отчёт также не отменяет проверку документации: инструмент обнаруживает не все возможные изменения.

Сохраните заявку до того, как начнёте её передавать

Где останется обращение, если n8n недоступен? Если браузер отправляет его прямо в n8n, а другой записи нет, сохранность заявки зависит от поведения формы и повторной отправки. Рассчитывать, что пользователь заметит проблему и попробует ещё раз, не стоит.

Для критичных форм можно предусмотреть промежуточное сохранение: серверная часть сайта записывает обращение в базу или надёжную очередь, а затем передаёт его в n8n. Каждой записи присваивается уникальный идентификатор и статус доставки. Подтверждение пользователю отправляется после успешного сохранения. Это отдельная доработка, которую проверяют до обновления. Приёмник должен работать независимо от n8n: запись первым узлом внутри обновляемого приложения проблему недоступности не решает.

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

Повторная отправка не должна создавать вторую сделку

Допустим, CRM создала карточку, но n8n не получил ответ. Если повторить запрос создания, может появиться дубль: два менеджера начнут работать с одним обращением, а отчётность посчитает его дважды.

Поэтому повторная обработка должна учитывать идентификатор исходной заявки. Если API CRM поддерживает защиту от повторных запросов, используйте её по правилам конкретного сервиса. В другом случае разработчику нужно организовать учёт уже обработанных событий и защиту от одновременного создания двух записей. Одна лишь проверка «найти, а если нет — создать» может не защитить от параллельных запросов.

Не путайте повторную доставку с новым обращением прежнего клиента. Удаление повторов только по телефону способно скрыть вторую потребность человека. Для защиты от дублей нужен идентификатор заявки.

Подготовьте восстановление, а не только архив

Разработчики отдельно предупреждают: прямого возврата с 3.x на 2.x нет. Чтобы вернуться, потребуется восстановление резервной копии. Поэтому план «поменяем версию обратно, если что-то сломается» для такого перехода не подходит.

Для самостоятельной установки нужно сохранить согласованный набор данных: базу n8n, постоянные тома и файлы, используемые сценариями, конфигурацию запуска, секреты и ключ шифрования. Состав зависит от конкретного размещения. Ключ особенно важен для доступа к зашифрованным учётным данным; экспорт схем workflow сам по себе полноценное восстановление не обеспечивает.

При организации резервного копирования заранее определите состав копии и место её хранения. Архив не должен быть доступен только внутри той установки, которую предстоит восстанавливать. Доступ к нему и секретам ограничивают, а способ создания согласованной копии выбирают с учётом используемой базы данных.

Проверьте восстановление копии в изолированной среде: сценарии должны открываться, подключения и файлы — быть доступны. До первого запуска отключите боевые триггеры и отправки клиентам, ограничьте внешние действия и подключите тестовую CRM.

Согласуйте условия восстановления: не проходит контрольная заявка, не активируются критичные сценарии или не сокращается очередь доставки. Допустимое время ожидания определяет бизнес с учётом нагрузки и возможности ручной обработки.

Проверьте результат глазами отдела продаж

На тестовой установке воспроизведите реальный способ поступления обращения. Проверьте карточку в CRM: контакты, источник, услугу, ответственного, вложения. После рабочего обновления повторите тест через действующую форму.

У Webhook в n8n разные адреса для тестового и рабочего режима. Кроме того, он может отвечать сразу после запуска сценария, не дожидаясь его завершения. Поэтому успешный ответ формы не всегда подтверждает запись в CRM. 

Минимальный набор проверок можно согласовать в одной таблице:

Для оповещения о неудачных выполнениях в n8n можно назначить error workflow с узлом Error Trigger. Но если сам n8n остановлен, полагаться только на его уведомления нельзя. Нужен внешний контроль доступности, а для заявок — контроль задержки между сохранением обращения и подтверждением доставки.

Как провести рабочее обновление

Выберите период с меньшим потоком обращений и назначьте ответственных за сервер, интеграцию и проверку CRM. До начала убедитесь, что резервный приём работает. Затем по подготовленному плану ограничьте запуск новых обработок, разберитесь с выполняющимися и ожидающими заданиями, создайте финальную согласованную копию и выполните переход.

Рабочую систему переводят на проверенный стабильный выпуск. Версию контейнера следует закрепить явно. Если используются отдельные процессы и исполнители, их версии нужно согласовать: документация требует одинаковой версии n8n на основных процессах, workers и обработчиках webhook. Само наличие нескольких процессов не гарантирует обновление без простоя.

После запуска проверьте активацию сценариев и контрольные обращения. Затем возобновляйте доставку с учётом ограничений CRM. Сверяйте ID сохранённых и доставленных заявок, а не число запусков workflow. При восстановлении из копии учитывайте сделки, которые уже появились в CRM после создания этой копии.

Переход завершён, когда известна судьба каждого обращения за период работ: доставлено, ожидает повтора или требует ручной проверки. Такой контроль пригодится и после n8n 3.0 — при следующем обновлении, сбое CRM или изменении формы.