n8n для бизнеса: собрать и проверить автоматизацию — значит построить один сценарий заявка с формы → запись в Data table → сообщение менеджеру в Telegram и провести его приёмку: ручной прогон на тестовом webhook, автоматический запуск опубликованной копии с намеренным сбоем, затем успешный production-запуск. Ниже — порядок сборки и проверки.
Сборка сценария: Webhook, проверка полей, Data table, Telegram
Сценарий начинается с узла Webhook. В документации n8n он описан как триггер, который принимает данные от приложений и сервисов при наступлении события и запускает workflow; тот же узел умеет возвращать данные, полученные в конце работы, что делает его пригодным для обработки запросов наподобие API-эндпоинта (docs.n8n.io). Для формы заявки это точка входа: клиент отправляет POST, n8n стартует выполнение.
После Webhook добавьте Edit Fields (Set) и подготовьте четыре выходных поля: name, phone, source, date. Значения перетащите из фактических входных данных контрольной заявки; проверьте предварительный результат каждого выражения. Так выходные поля получат нужные имена даже при вложенной структуре заявки. В официальном quickstart этот способ показан на поле report: Add Field задаёт имя, а перетаскивание значения из входной панели создаёт выражение (docs.n8n.io).
Затем подключите ноду проверки обязательных полей. Условие пропускает заявку дальше, только когда name, phone, source и date заполнены. Ветвь с пустыми значениями завершите без записи и уведомления; к ветви заполненной заявки подключите Data table.
В Personal → Data tables создайте таблицу заявок с колонками name, phone, source, date. В ноде Data table выберите действие Insert row, эту таблицу и Mapping Column Mode → Map Automatically. Перед запуском проверьте, что входной элемент ноды содержит эти четыре поля на верхнем уровне. Автоматическое сопоставление по совпадающим именам показано в официальном quickstart (docs.n8n.io).
Уведомление менеджеру идёт через узел Telegram, ресурс Message, операция Send Message. В документации узла указано: нужна отдельная credential, а бота требуется добавить в чат или канал, куда он будет писать (docs.n8n.io). Токен бота выдаёт BotFather по команде /newbot, и этот токен хранится в credential n8n (docs.n8n.io). Текст сообщения ограничен 4096 символами, по умолчанию применяется HTML-разбор (docs.n8n.io).
Храните секретный токен в credential. Исключите его из текста нод, экспортируемого workflow и логов.
| Шаг | Узел | Что настраиваем |
|---|---|---|
| Триггер | Webhook | HTTP-метод POST, путь, режим ответа |
| Проверка | Условие | Обязательные поля: имя, телефон, источник, дата |
| Запись | Data table, Insert row | Таблица заявок, сопоставление колонок |
| Уведомление | Telegram, Send Message | Credential, Chat ID, текст до 4096 символов |
Тестовый и production webhook URL: в чём разница при отладке
У узла Webhook два адреса, и n8n показывает их в верхней части панели ноды с переключателем между ними (docs.n8n.io). Тестовый URL регистрируется, когда вы выбираете Listen for Test Event или запускаете Execute workflow при неактивном workflow; при вызове этого адреса n8n показывает полученные данные прямо в редакторе (docs.n8n.io). Production URL регистрируется при публикации workflow; данные в редакторе при этом не отображаются, а выполнение смотрят во вкладке Executions (docs.n8n.io).
Практический вывод для отладки: пока сценарий собирается, вызовы идут на тестовый адрес, и входные данные видны сразу. После публикации внешняя система должна обращаться к production-адресу, а разбор запусков переезжает в Executions. Смешение адресов — частая причина «пустого» прогона: форма стучится на production, а вы ждёте данные в редакторе.
Полезные параметры того же узла: максимальный размер полезной нагрузки — 16 МБ, при самостоятельном хостинге меняется переменной окружения N8N_PAYLOAD_SIZE_MAX (docs.n8n.io). Путь по умолчанию генерируется случайно, чтобы не конфликтовать с другими webhook-нодами, но его можно задать вручную, в том числе с параметрами маршрута (docs.n8n.io).
Отдельно про режим ответа. При значении Immediately узел возвращает код и сообщение о том, что workflow запущен; при When Last Node Finishes возвращается код и данные последней выполненной ноды (docs.n8n.io). Для формы первый вариант удобен скоростью, но успешный ответ в этом режиме означает только старт выполнения.
| Свойство | Тестовый URL | Production URL |
|---|---|---|
| Когда регистрируется | Listen for Test Event или Execute workflow | Публикация workflow |
| Видны ли данные в редакторе | Да | Нет |
| Где смотреть запуск | Редактор | Вкладка Executions |
| Кто вызывает | Вы при отладке | Внешняя система |
Ручной прогон: Execute workflow и фактическая запись
Ручная проверка начинается с кнопки Execute workflow. В обучающем материале n8n после запуска предлагается открыть таблицу и убедиться, что n8n вставил строку (docs.n8n.io). Это и есть критерий: смотрим не на зелёный статус ноды, а на новую строку в Data table.
Для контрольного POST используйте JSON {«name»:»Тестовая заявка»,»phone»:»ТЕСТ»,»source»:»форма сайта»,»date»:»дата прогона»}; date замените фактической датой проверки. Отправьте его на тестовый webhook URL, затем проверьте выход Edit Fields и строку в Data table. Для второго прогона оставьте phone пустым: строка и сообщение менеджеру появиться не должны.
Порядок ручной проверки:
- Выберите Listen for Test Event и отправьте контрольную заявку на тестовый URL.
- Убедитесь, что нода проверки пропустила заполненные поля и отсекла пустые — прогоните оба варианта.
- Откройте Data table и проверьте фактическую строку: значения колонок совпадают с отправленными.
- Проверьте доставку сообщения в Telegram: текст содержит данные заявки, сообщение пришло в нужный чат.
- Посмотрите Executions: запуск завершён, ошибок нет.
Отдельно проверьте режим ответа. Если Webhook отвечает Immediately, клиент получает подтверждение старта, и по этому ответу нельзя судить о записи и доставке. Ориентир — строка в таблице и сообщение в чате.
Частая ошибка ручного этапа — считать успешный HTTP-ответ доказательством работы сценария. Второй источник путаницы — проверка только на заполненной заявке: пустые обязательные поля стоит прогнать тем же путём, чтобы увидеть, как срабатывает условие.
Error Trigger: отдельный workflow и привязка в настройках
Обработчик ошибок — отдельный workflow с цепочкой Error Trigger → Telegram. Создайте его, назовите Error Handler и после Error Trigger добавьте Telegram: Resource → Message, Operation → Send Message. Выберите credential и целевой Chat ID. В Text составьте сообщение «Сбой: [имя workflow]; [текст ошибки]», подставляя значения из фактического выхода Error Trigger через выражения. Сохраните обработчик. Затем в целевом сценарии откройте Options → Settings, в поле Error workflow выберите Error Handler и сохраните. Порядок привязки описан в документации Error Trigger, параметры отправки — в разделе Telegram Send Message (docs.n8n.io). Один обработчик допускается использовать для нескольких workflow (docs.n8n.io).
Два свойства, важных для приёмки. Если workflow содержит Error Trigger, публиковать его не требуется (docs.n8n.io). И обработчик не тестируется при ручном запуске: Error Trigger срабатывает, когда автоматический workflow завершается ошибкой (docs.n8n.io). Отсюда следует порядок: ручной Execute проверяет сборку, а работу обработчика проверяют отдельно, автоматическим запуском.
Что приходит в обработчик: сведения о сбойном workflow и ошибке. Поля execution.id и execution.url требуют, чтобы выполнение сохранилось в базе, и отсутствуют, если ошибка возникла в триггерной ноде основного workflow, поскольку выполнение не стартовало; execution.retryOf появляется только при повторе неудачного запуска (docs.n8n.io). Если сбой произошёл именно в триггере, в обработчик уходит меньше данных в execution и больше в trigger (docs.n8n.io).
Практический вывод для текста уведомления: не полагайтесь только на execution.url. Добавьте имя workflow и текст ошибки — они приходят всегда, а ссылка на выполнение может не прийти при сбое в триггере.
| Что проверяем | Как проверяем | Ожидаемый результат |
|---|---|---|
| Привязка обработчика | Options → Settings → Error workflow | Выбран нужный workflow |
| Публикация обработчика | Не требуется | Обработчик работает без публикации |
| Ручной запуск | Execute workflow целевого сценария | Error Trigger не срабатывает |
| Данные ошибки | Автоматический сбой | Пришли имя workflow и текст ошибки |
Приёмка обработчика: Production URL и намеренный Stop And Error
Проверка обработчика требует автоматического запуска. Для этого сделайте учебную копию сценария, добавьте в неё узел Stop And Error и опубликуйте копию. Узел Stop And Error заставляет выполнение завершиться ошибкой по выбранному вами условию и запускает error workflow (docs.n8n.io). Опубликованная копия получает production webhook URL, и вызов этого адреса запускает выполнение автоматически.
Порядок приёмочного сбоя:
- Скопируйте рабочий сценарий в учебную копию и назовите её явно, например «Приёмка: сбой».
- Поставьте Stop And Error после проверки полей, чтобы сбой шёл по контролируемому пути.
- Опубликуйте копию и убедитесь, что обработчик привязан в её настройках.
- Отправьте контрольную заявку на production URL копии.
- Откройте Executions: выполнение завершилось ошибкой.
- Проверьте доставку уведомления от обработчика в Telegram.
Проверьте доставку уведомления: сообщение должно появиться в целевом чате. Если обработчик пишет в тот же чат, что и рабочий сценарий, различайте сообщения по тексту — добавьте пометку о сбое.
Ручной запуск здесь не подходит: Error Trigger срабатывает только при автоматическом сбое (docs.n8n.io). Поэтому учебная копия публикуется, а вызов идёт по production-адресу.
| Шаг приёмки | Действие | Подтверждение |
|---|---|---|
| 1 | Учебная копия со Stop And Error | Копия сохранена |
| 2 | Публикация копии | Есть production URL |
| 3 | Вызов production URL | Запуск появился в Executions |
| 4 | Проверка статуса | Выполнение с ошибкой |
| 5 | Проверка уведомления | Сообщение о сбое в Telegram |
Снятие испытательного условия и успешный production-запуск
После подтверждённой доставки уведомления уберите или отключите узел Stop And Error в учебной копии. Если узел отключён, он остаётся на холсте, но не влияет на выполнение; если удалён — цепочка сокращается. Для приёмки удобнее отключение: видно, что именно проверялось.
Затем повторите запуск по production URL и убедитесь в успешном результате. Критерии те же, что и на ручном этапе, но теперь выполнение автоматическое: строка появилась в Data table, сообщение дошло до менеджера, запуск в Executions завершён без ошибок. Обработчик при этом не должен сработать — уведомления о сбое быть не должно.
Порядок повторного запуска:
- Отключите или удалите Stop And Error в учебной копии.
- Сохраните изменения; при необходимости опубликуйте копию заново.
- Отправьте контрольную заявку на production URL.
- Проверьте новую строку в Data table.
- Проверьте сообщение менеджеру в Telegram.
- Убедитесь, что уведомление об ошибке не пришло.
Отдельно проверьте поведение при пустых обязательных полях уже на production: условие должно отсечь заявку, а менеджер не должен получить сообщение. Это граничный случай, который чаще всего всплывает после запуска.
Когда успешный production-запуск подтверждён, учебную копию можно удалить или оставить как стенд для будущих проверок. Рабочий сценарий продолжает жить отдельно.
Чек-лист приёмки автоматизации
Сведите проверки в одну таблицу и проходите её при каждом изменении сценария. Колонки: что проверяем, как проверяем, ожидаемый результат.
| Что проверяем | Как проверяем | Ожидаемый результат |
|---|---|---|
| Приём заявки | POST на тестовый URL | Данные видны в редакторе |
| Обязательные поля | Заявка с пустым полем | Условие отсекает заявку |
| Запись строки | Открыть Data table | Строка с данными заявки |
| Уведомление | Проверить Telegram | Сообщение в нужном чате |
| Режим ответа | Смотреть ответ Webhook | Понятно, что ответ значит старт |
| Привязка обработчика | Options → Settings | Выбран Error workflow |
| Сбой | Production URL копии со Stop And Error | Ошибка в Executions, уведомление доставлено |
| Успех | Production URL после снятия условия | Строка, сообщение, нет уведомления о сбое |
Держите контрольные данные постоянными: одинаковый набор полей позволяет сравнивать запуски между собой. Если меняете схему таблицы, обновите и контрольную заявку.
Частые вопросы
Чем тестовый webhook URL отличается от production при отладке?
Тестовый адрес регистрируется при выборе Listen for Test Event или запуске Execute workflow и показывает данные прямо в редакторе. Production-адрес регистрируется при публикации, данные в редакторе не отображает, а запуски видны во вкладке Executions. Для отладки удобен тестовый, для внешних систем — production.
Почему ручной запуск не проверяет обработчик ошибок?
Error Trigger срабатывает, когда автоматический workflow завершается ошибкой. При ручном запуске он не активируется. Поэтому приёмка сбоя идёт через публикацию учебной копии и вызов production-адреса.
Нужно ли публиковать workflow с Error Trigger?
Нет, публикация для него не требуется. Обработчик достаточно создать, сохранить и привязать в настройках целевого сценария. Один обработчик можно использовать для нескольких workflow.
Достаточно ли успешного ответа Webhook, чтобы считать сценарий рабочим?
Нет. В режиме Immediately узел возвращает только сообщение о старте выполнения. Работоспособность подтверждают фактическая строка в Data table, доставленное сообщение в Telegram и запись запуска в Executions.
Что проверить в сообщении об ошибке?
Имя workflow и текст ошибки приходят всегда. Поля execution.id и execution.url требуют сохранения выполнения в базе и отсутствуют при сбое в триггерной ноде. Ссылку на выполнение стоит дополнять текстовыми сведениями.