Маршрутизация и сохранение результата

В предыдущем уроке workflow получил цепочку нормализации и валидации: Edit Fields приводил данные к единому формату, а узел IF проверял обязательное поле email — невалидные заявки уходили в Stop and Error. Теперь к ветке валидных данных (выход false валидационного IF) добавляется новая логика: разделение заявок по приоритету.

Второй узел IF: разделение заявок на приоритетные и обычные

Когда заявка прошла валидацию, workflow знает о ней главное: все обязательные поля заполнены, данные нормализованы. Теперь можно принимать содержательное решение — куда её направить. Для этого в ветку валидных данных добавляется второй узел IF. Его задача принципиально отличается от первого: валидационный IF работал как фильтр — он отсекал плохие данные и останавливал обработку. Маршрутизирующий IF делит поток надвое, и оба выхода ведут к продолжению работы. Нет «плохого» и «хорошего» пути — есть два разных сценария обработки.

Условие строится по полю priority. Если значение равно 'Срочно' — item уходит в ветку true. Все остальные значения ('Обычная', пустая строка, что угодно ещё) — в ветку false. В интерфейсе n8n это выглядит так:

• Value 1: {{ $json.priority }}
• Operation: Equal
• Value 2: Срочно

Поскольку данные прошли нормализацию в предыдущем уроке, поле priority уже приведено к единому формату — это делает условие ветвления предсказуемым.

В итоге workflow содержит два узла IF подряд, и это нормальный паттерн: каждый решает свою задачу. Первый — «эта заявка вообще годится к обработке?», второй — «в какую очередь она попадает?». Смешивать их в один узел не стоит: условие стало бы сложнее, а диагностировать ошибки — тяжелее.

Сохранение обеих категорий в Data Table

Data Table — это встроенное хранилище n8n, удобное для прототипирования и учебных сценариев: никакой внешней базы данных подключать не нужно, результаты видны прямо внутри workflow.

Чтобы записать строку в таблицу, узел Data Table нужно настроить так:

• Resource: Row
• Operation: Insert
• Table: выбрать нужную таблицу из выпадающего списка
• Map Automatically: включить

При включённом Map Automatically узел сам сопоставляет поля item с колонками таблицы по именам. Если имена совпадают — данные ложатся в нужные ячейки без ручного маппинга. Если структура item отличается от структуры таблицы, маппинг придётся настраивать вручную.

Перед тем как подключать узлы, нужно создать сами таблицы. Это делается в разделе Data tables в боковом меню n8n:

1. Создать таблицу priority_requests с колонками name, priority, email.

2. Создать таблицу regular_requests с теми же колонками.

Теперь — подключение. К ветке true маршрутизирующего IF подключается узел Data Table, настроенный на priority_requests. К ветке false — отдельный узел Data Table на regular_requests. Это два независимых узла, каждый со своей таблицей. Каждый item проходит только через одну ветку, поэтому дублирования не будет: приоритетная заявка попадёт только в priority_requests, обычная — только в regular_requests.

Как это выглядит на конкретных данных. Workflow получает два item:

{ "name": "Иван", "priority": "Срочно", "email": "ivan@example.com" }
{ "name": "Мария", "priority": "Обычная", "email": "maria@example.com" }

Узел IF проверяет {{ $json.priority === 'Срочно' }}:

• Иван → ветка true → Data Table priority_requests → в таблице появляется строка с его данными.
• Мария → ветка false → Data Table regular_requests → в таблице появляется строка с её данными.

После тестового запуска в Output каждого узла Data Table видна ровно одна строка. Именно это нужно проверять: если в priority_requests нет ни одной записи при заявке со значением 'Срочно' — скорее всего, ветка IF подключена неправильно или имена колонок в таблице не совпадают с именами полей item.

Разветвление заявок по приоритету и сохранение в Data Table.

Опциональное уведомление при наличии credentials

После того как приоритетная заявка записана в priority_requests, можно добавить следующий шаг — отправить уведомление: в Telegram, на email или в любой другой канал. Но этот шаг необязателен: без него workflow работает полностью корректно. Уведомление — это расширение, а не часть основной логики.

Паттерн здесь простой: узел уведомления (например, Telegram или Send Email) подключается к выходу узла Data Table priority_requests — то есть встаёт последним в ветке true. Если credentials для этого узла настроены, он отработает и отправит сообщение. Если credentials не заданы — узел нужно либо не подключать вовсе, либо временно отключить.

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

Важный момент: если узел уведомления стоит последним в ветке и выдаёт ошибку из-за отсутствия credentials, это не ломает ветку false с обычными заявками — та работает независимо. Ошибка локализована внутри одной ветки.

Если credentials сейчас недоступны, правильное решение — отключить узел через меню узла → Disable. Тогда n8n просто пропустит его при выполнении, и вся остальная цепочка отработает без изменений. Когда credentials появятся — включаешь узел обратно, и он сразу включается в работу.

Это и есть принцип условного расширения: основной workflow не зависит от наличия конкретного внешнего сервиса. Уведомление подключается тогда, когда оно реально доступно, и отключается без последствий для остального.

Типичные ошибки: забытая ветка и узел без credentials

Две ошибки в этом уроке встречаются чаще остальных — и обе легко не заметить, пока не запустишь тест.

Забытая ветка IF

Workflow собран, первый тестовый запуск прошёл — но при проверке таблиц оказывается, что regular_requests пуста. Форма принимала и обычные заявки, однако в таблицу они не попали. Причина почти всегда одна: узел Data Table подключён только к ветке true маршрутизирующего IF, а ветка false висит в воздухе. Когда n8n доходит до развилки и item уходит в false, дальше для него нет ни одного узла — он просто исчезает из потока без какой-либо ошибки. Workflow считает это нормой: незаполненная ветка не вызывает предупреждений.

Диагностика простая: после тестового прогона откройте Output каждого узла Data Table. Если один из них показывает 0 строк при том, что вы точно отправляли подходящие данные — значит, к этой ветке IF ничего не подключено. Проверьте холст: у маршрутизирующего IF должны быть два исходящих соединения, каждое ведёт к своему узлу Data Table.

Исправление: добавить отдельный узел Data Table для regular_requests и подключить его к ветке false. После этого оба потока замкнуты.

Узел уведомления без credentials

Вторая ошибка возникает, когда узел Telegram или Send Email добавлен в ветку, но учётные данные к нему не привязаны. Внешне это выглядит так: после запуска узел уведомления окрашивается в красный, а в панели выполнения появляется сообщение об ошибке аутентификации — как правило, вида «401 Unauthorized» или «No credential found». Это не абстрактный сбой, а конкретный сигнал: узел знает, что делать, но не знает, от чьего имени.

Важный диагностический момент: ошибка красит только сам узел уведомления, а не всю ветку. Если открыть Output узла Data Table priority_requests, стоящего перед ним, — там будут корректные данные. Ветка false с обычными заявками при этом отрабатывает полностью независимо. То есть workflow частично сломан: обе таблицы заполняются корректно, но уведомление не уходит — и без внимательного просмотра холста это легко пропустить.

Если credentials сейчас недоступны — отключите узел через Disable и протестируйте остальную цепочку. Когда credentials будут настроены в поле Credential настроек узла, включите узел обратно: ошибка исчезнет и он включится в нормальную работу ветки.