Маршрутизация и сохранение результата
Содержание курса
В предыдущем уроке 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:EqualValue 2:Срочно
Поскольку данные прошли нормализацию в предыдущем уроке, поле priority уже приведено к единому формату — это делает условие ветвления предсказуемым.
В итоге workflow содержит два узла IF подряд, и это нормальный паттерн: каждый решает свою задачу. Первый — «эта заявка вообще годится к обработке?», второй — «в какую очередь она попадает?». Смешивать их в один узел не стоит: условие стало бы сложнее, а диагностировать ошибки — тяжелее.
