Сквозной проект: обработка заявки

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

Содержание курса

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