Условия в n8n: If, Switch, Merge и ловушка, из-за которой горячие заявки теряются

12 октября 2026 г. · 5 мин чтения · Редакция Skill Unit

Когда заявок становится больше, одной цепочки узлов не хватает. Студия потолков хочет, чтобы горячие заявки (бюджет от 100 000 ₽) сразу шли старшему замерщику, заявки с Авито попадали в отдельный лист, а вечерние ждали утра. Для этого нужны развилки.

Главная особенность: условие считается для каждого элемента

В n8n условие проверяется для каждого элемента отдельно. Если в узел If пришли пять заявок, три могут уйти в ветку true, две — в false, и дальше по каждой ветке пойдёт столько элементов, сколько туда попало. Поэтому одна и та же схема одинаково работает для одной заявки и для сотни. Ветка при этом может оказаться пустой, если ни одна заявка не подошла.

If и Switch

• If делит поток на две ветки: true и false. Условие собирают из сравнений с учётом типа данных (текст, число, дата, логическое значение, массив, объект) и объединяют через AND или OR.
• Switch нужен, когда выходов больше двух. В режиме Rules каждое правило отправляет элемент в свой выход, есть выход Fallback для всего остального. В режиме Expression вы пишете выражение, которое возвращает номер выхода, и задаёте их число. Нумерация выходов начинается с нуля.
• Первый режим понятнее и подходит почти всегда. Оператор «? :» внутри формулы работает как маленький If, но после трёх вложений такую формулу уже никто не прочитает.

Что решить заранее: куда отправить заявку, которая подходит сразу под два правила (горячая и с Авито). Если разные люди получают разные задачи, пригодится режим «во все подходящие выходы». Если достаточно одного звонка, оставьте режим по умолчанию и поставьте горячее правило первым. Хуже всего, когда настройка выбрана случайно, а часть заявок тихо исчезает из-за Fallback = None.

Ловушка: бюджет пришёл текстом

Форма даёт клиенту свободное поле. Значение «120000» встречается реже, чем «120 000», «120 000 ₽» или «от 100 тыс». Функция Number() с такими строками обходится не так, как вы ожидаете.

Реальная история из учебного кейса: в пятницу вечером пришла заявка на ремонт всей квартиры, клиент написал в «Бюджет» «120 000 ₽». Сценарий брал {{ Number($json.budget) }} и сравнивал со 100000. Number("120 000 ₽") даёт NaN, любое сравнение с NaN ложно, заявка ушла в ветку false вместе с мелкими работами, и старший замерщик узнал о ней в понедельник. Сценарий не показал ни одной ошибки: узлы зелёные, заявка записана. Именно поэтому такие ошибки опасны.

• Не полагайтесь на Number() для свободного поля. Сначала очистите строку: уберите пробелы и всё, кроме цифр, и только потом превращайте в число.
• Добавьте явную ветку для значений, которые не удалось разобрать: «бюджет не распознан». Пусть они идут человеку, а не в обычные.
• Тестируйте на живых формулировках: «120000», «120 000», «120 000 ₽», «от 100 тыс», пусто.

Merge: как склеить данные

Узел Merge собирает данные из нескольких входов. Основные режимы: Append (положить элементы одного входа после другого), Combine (объединить поля по совпадению значений, по позиции или всеми парами), SQL Query и Choose Branch. В режиме по совпадению полей поведение выбирают параметром Output Type.

• Keep Matches (по умолчанию) оставляет только пары, нашедшие друг друга: как внутреннее соединение в базах данных.
• Keep Non-Matches оставляет только несовпавшие.
• Keep Everything оставляет и пары, и несовпавшие.
• Enrich Input 1 сохраняет все элементы первого входа и добавляет данные второго, если они нашлись.

Пример. Пять заявок и прайс: услуга «потолок» есть у заявок 1, 2 и 5, «карниз» у заявки 3, а «окна» (заявка 4) в прайсе нет. Keep Matches даст пары для заявок 1, 2, 3 и 5, а заявка 4 без пары в результат не попадёт, и менеджер не увидит запроса на окно. Enrich Input 1 оставит все пять заявок, у четырёх добавится цена, у четвёртой цены не будет. Для заявок обычно нужен именно такой режим.

• Если в обоих входах есть поле с одинаковым названием, по документации n8n при слиянии побеждает значение из входа 2. Переименуйте поля заранее или выберите Clash Handling.
• Сравнение значений строгое: «3» и 3 по умолчанию разные. Чтобы это изменить, включите Fuzzy Compare.

Циклы и вечерние заявки

Большинство узлов уже обрабатывают все элементы по очереди, поэтому цикл нужен реже, чем кажется: когда у сервиса есть ограничение частоты запросов, когда надо отправлять порциями или делать паузы. Для этого есть Loop Over Items (раньше Split in Batches).

Правило студии: заявки с 20:00 до 9:00 замерщикам не отправляются. Самый простой способ — поставить узел Wait до 9:00 следующего дня, но у него минусы: каждая вечерняя заявка превращается в отдельный «спящий» запуск, и Wait считает по времени сервера, а не по часовому поясу сценария. Для большой нагрузки лучше складывать вечерние заявки в таблицу и отправлять утром отдельным сценарием по расписанию.

Узел Code: когда нужен

Code позволяет написать JavaScript или Python. Есть режимы Run Once for All Items и Run Once for Each Item. Выбирайте его, когда стандартными узлами и выражениями задачу решить сложно: нестандартная группировка, сложный расчёт, склейка элементов. Секреты (токены, пароли) в код не вставляйте. И помните про ту же болезнь: если код делает Number() из строки «120 000 ₽», получится NaN.

Что делать дальше

Соберите маленький сценарий: Webhook, узел очистки бюджета, If по порогу и отдельная ветка для нераспознанных значений. Отправьте ему пять заявок с разными формулировками бюджета и убедитесь, что ни одна не потерялась. В курсе «Автоматизация без кода на n8n» на Skill Unit логике сценария посвящён отдельный урок с практикой. Первые уроки бесплатны.