В n8n можно отправить подходящие записи по одной ветке, а остальные - по другой. Для этого нужен узел If. Разберём его на пяти вымышленных заявках: проверим бюджет, логический флаг и непустое сообщение. Вы увидите, куда попала каждая запись, и проверите разницу между AND и OR.
Результат инструкции
Соберём Manual Trigger → Test Requests → Split Requests → Check Request. Выход true ведёт в Ready for Review, выход false - в Needs Check. На исходных данных первая ветка получит A1 и A5, вторая - A2, A3 и A4. Каждый выход добавит понятный статус, сохранив исходные поля заявки.
Все действия остаются внутри результата выполнения. Схема не пишет в CRM, не отправляет письма и не обращается к модели. If не оценивает смысл сообщения и не является AI-агентом: он проверяет правила, которые мы задали.
Что понадобится
- Запущенный n8n и доступ к созданию нового workflow. Инструкция проверена на версии 2.42.4.
- Пустая отдельная схема. Старые workflows не меняйте.
- Готовый JSON из следующего шага. API-ключи, аккаунты внешних сервисов и оплата для упражнения не нужны.
Установить n8n локально через Docker
Шаг 1. Создайте новый workflow
Откройте Overview → Create workflow. Убедитесь, что холст пустой. Не тестируйте смену условий на рабочей схеме с рассылкой, платежами или записью данных. Для ручного выполнения этого примера Publish не требуется.
Шаг 2. Импортируйте готовую схему
Скачать n8n-if-routing-demo.json
Скопируйте весь текст файла, щёлкните свободную область холста и нажмите Ctrl+V. Должны появиться шесть узлов и имя ezgpt-if-routing-demo. Нажмите Zoom to Fit. Проверьте соединения: верхний true у Check Request идёт в Ready for Review, нижний false - в Needs Check.
Если узлы уже есть на холсте, не вставляйте JSON повторно поверх них: можно получить вторую цепочку. Начните с нового пустого workflow. В меню More actions также может быть Import from File.
Шаг 3. Проверьте исходные заявки
Дважды щёлкните значок Test Requests. Это Edit Fields в режиме JSON Output. В поле JSON должен быть объект с массивом requests:
Показать код (34 строк)
{
"requests": [
{
"id": "A1",
"budget": 15000,
"consent": true,
"message": "Нужна консультация по автоматизации"
},
{
"id": "A2",
"budget": 9000,
"consent": true,
"message": "Хочу обсудить небольшой проект"
},
{
"id": "A3",
"budget": 20000,
"consent": false,
"message": "Проверяю варианты"
},
{
"id": "A4",
"budget": 25000,
"consent": true,
"message": " "
},
{
"id": "A5",
"budget": 10000,
"consent": true,
"message": "Запрос на минимальный проект"
}
]
}Здесь budget - число, consent - Boolean true или false, message - строка. Кавычки у "true" превратили бы Boolean в текст. id нужен для сверки маршрута. Поле consent в этом упражнении - только учебный флаг, не подтверждение юридического согласия на обработку данных или рекламу.
Нажмите Execute step. OUTPUT должен содержать один item с пятью объектами внутри requests. Один item ещё не означает одну заявку: следующий узел разделит массив.
Шаг 4. Разделите массив на отдельные записи
Откройте Split Requests - это Split Out. Fields To Split Out = requests, Include = No Other Fields. В Options не задавайте Destination Field Name. После Execute step в OUTPUT → Table должно быть пять items с полями id, budget, consent и message на верхнем уровне.
Поэтому в следующем узле обращаемся к $json.budget, а не к $json.requests.budget. Если добавить обёртку через Destination Field Name, структура изменится. Для этого примера оставьте настройки из файла.
Разобраться с массивом и Split Out
Шаг 5. Настройте числовое условие
Откройте Check Request - узел If. В первом условии левое значение работает в режиме Expression:
{{ typeof $json.budget === 'number' && Number.isFinite($json.budget) ? $json.budget : -1 }}Тип сравнения Number, оператор is greater than or equal to, правое значение в режиме Fixed = 10000. Смысл: бюджет не меньше 10 000. Граница включена, поэтому A5 с ровно 10000 должен пройти эту проверку.
Выражение слева возвращает число только для числового budget; строка, null или отсутствующее поле дают -1 и не проходят порог. Так неправильный тип не останавливает всю учебную цепочку и не принимается за корректный бюджет. Значение -1 - технический маркер проверки, исходный budget в заявке не меняется.
Шаг 6. Проверьте флаг и сообщение
Во втором условии левое значение в режиме Expression, тип Boolean, оператор is true:
{{ $json.consent === true }}Только настоящий Boolean true даёт положительный результат. Текст "true", false и отсутствие поля его не дают. В третьем условии выберите такой же тип Boolean и оператор is true, но другое выражение:
{{ typeof $json.message === 'string' && $json.message.trim().length > 0 }}Оно проверяет, что message - строка и после удаления пробелов по краям в ней остаётся текст. Сообщение из трёх пробелов у A4 не подходит. Проверка типа перед trim() защищает от ошибки на null или объекте. Она не проверяет достоверность или полезность сообщения.
Шаг 7. Оставьте AND и проверьте типы
В выпадающем списке между условиями выберите AND. Это значит, что все три проверки должны пройти одновременно. В этой схеме Convert types where required выключен: преобразование текстовых значений не используется как способ обойти проверку типов.
На выход true идёт запись, выполнившая все условия; на false - запись, у которой хотя бы одно не выполнено. Правила учебные: бюджетный порог не означает, что заявку надо удалить, а флаг true не разрешает автоматически писать человеку. Поэтому обе ветки только ставят статусы.
n8n: условия If и комбинации AND/OR
Шаг 8. Проверьте статусы обеих веток
Откройте Ready for Review. Это Edit Fields, Mode = Manual Mapping. Два строковых поля: status = ready_for_review и routing_reason = all_demo_rules_passed. Оба значения в режиме Fixed. Include Other Input Fields включён, чтобы id, budget, consent и message остались в результате.
В Needs Check такие же настройки, но status = needs_check и routing_reason = one_or_more_demo_rules_failed. Это общий признак провала одного или нескольких правил, а не точный перечень ошибок. Не называйте его объяснением каждой причины.
В Settings этих узлов не включайте Execute Once. Каждая ветка должна обработать все пришедшие в неё items, а не только первый.
Шаг 9. Выполните всю цепочку
Закройте узлы и нажмите Execute workflow на холсте. Откройте Check Request → OUTPUT. True Branch должна содержать два items, False Branch - три. Затем откройте конечные узлы и сравните ID:
- A1 → Ready for Review: бюджет 15000, флаг true, сообщение есть.
- A2 → Needs Check: бюджет 9000 ниже порога.
- A3 → Needs Check: consent = false.
- A4 → Needs Check: message содержит только пробелы.
- A5 → Ready for Review: бюджет ровно 10000, остальные проверки проходят.
Первая запись Ready for Review в нашем проверенном выполнении:
{
"id": "A1",
"budget": 15000,
"consent": true,
"message": "Нужна консультация по автоматизации",
"status": "ready_for_review",
"routing_reason": "all_demo_rules_passed"
}Первая запись Needs Check:
{
"id": "A2",
"budget": 9000,
"consent": true,
"message": "Хочу обсудить небольшой проект",
"status": "needs_check",
"routing_reason": "one_or_more_demo_rules_failed"
}Сумма записей в двух выходах равна пяти; ID не повторяются и не пропадают. If сам не добавляет status: поле появляется после Edit Fields. Ветвление выполняется для каждого item, поэтому в одном запуске обе ветки могут получить данные.
Шаг 10. Проверьте, что изменит OR
В Check Request временно переключите AND на OR, закройте узел и выполните весь workflow заново. В этом наборе все пять заявок попадут в Ready for Review, а Needs Check не получит новых данных. У каждой записи проходит хотя бы одно правило, даже у A3 с false или A4 с пробелами.
Это ожидаемый результат OR, а не ошибка If. Именно поэтому OR нельзя включать ради того, чтобы «что-нибудь прошло», если нужны все обязательные проверки. Верните AND и повторите полный запуск: снова должны получиться две и три записи.
После изменения условий не ориентируйтесь на старый OUTPUT узла, который не участвовал в новом запуске. Например, при OR у Needs Check может оставаться прежний результат на экране. Проверяйте выход Check Request и данные конкретного нового выполнения.
Шаг 11. Проверьте неправильные типы и пустой текст
В Test Requests временно замените JSON следующим объектом. Это семь новых учебных записей, каждая с проблемой:
Показать код (47 строк)
{
"requests": [
{
"id": "E1",
"budget": "15000",
"consent": true,
"message": "Текст"
},
{
"id": "E2",
"budget": 15000,
"consent": "true",
"message": "Текст"
},
{
"id": "E3",
"budget": null,
"consent": true,
"message": "Текст"
},
{
"id": "E4",
"budget": 15000,
"consent": true
},
{
"id": "E5",
"budget": 15000,
"consent": true,
"message": null
},
{
"id": "E6",
"budget": 15000,
"consent": true,
"message": {
"text": "Текст"
}
},
{
"id": "E7",
"budget": 15000,
"consent": true,
"message": "\t\n "
}
]
}Запустите весь workflow при AND. Ожидается ноль items в True Branch и семь в False Branch, без ошибки trim() или числового сравнения. E1 содержит бюджет текстом, E2 - флаг текстом, E3 - null вместо бюджета, E4 - нет message, E5 - null, E6 - объект вместо сообщения, E7 - только пробельные символы.
Если настоящая форма присылает числа строками, нормализуйте их отдельным шагом по явным правилам, затем проверяйте диапазон. Не заменяйте проверку consent на Boolean(value): непустая строка "false" в JavaScript тоже превращается в true. В этой схеме такие строки сознательно отправляются на проверку.
Шаг 12. Проверьте пустой список и восстановите пример
Для последнего теста поставьте в Test Requests:
{"requests":[]}Выполните весь workflow. Split Requests вернёт ноль items; Check Request и обе конечные ветки не должны выполняться для этого нового запуска. Пустой список - это отсутствие записей, не одна «ложная» заявка. Не включайте Always Output Data только ради появления строки: это меняет поведение пустого входа.
Верните полный JSON из шага 3, AND и исходные настройки. Выполните цепочку ещё раз: A1/A5 в Ready for Review, A2/A3/A4 в Needs Check. Схема остаётся ручной и неопубликованной. Если всё совпало, упражнение закончено.
Если результат отличается
| Симптом | Что проверить | Ожидаемый результат |
|---|---|---|
| Все заявки в true | Комбинацию условий | AND, две записи |
| Пять заявок остаются одним item | Split Requests | Пять items до If |
| Ошибка на message.trim() | Проверку типа перед trim | null и объект идут в false |
| Бюджет 10000 не проходит | Оператор числового сравнения | is greater than or equal to |
| Пропали id и исходные поля | Include Other Input Fields | Включено в обеих конечных ветках |
| В неисполненном узле старый OUTPUT | Новое выполнение и выход If | Не считать старые данные новым результатом |
Перед подключением реальной формы
Замените учебные данные только после проверки структуры своего входа. В Webhook значения обычно находятся внутри body, поэтому выражения из примера нельзя переносить без сверки пути. Если на входе уже один item на заявку, Split Out может быть не нужен.
Следующий шаг: принять JSON через Webhook
Наш пример проверяет только четыре известных поля и не является полной валидацией формы. Он не проверяет уникальность id, допустимый максимум бюджета, адрес почты, права доступа или законность контакта. Для производства нужны отдельные правила, журнал ошибок и ручная проверка до внешних действий.
Не подключайте к учебной true-ветке оплату, удаление данных или массовую отправку. Если нужны три и более направления по значению, рассмотрите Switch вместо длинной цепочки If. Этот материал проверяет только два выхода, без Merge и без обработки технических ошибок API.
Что проверено редакцией
9 октября 2026 года схема проверена на n8n 2.42.4. Пять CLI-сценариев: исходный AND, OR, семь записей с неправильными типами или пустым текстом, пустой список и восстановление исходных данных. Все проверки прошли. В локальном редакторе создан новый workflow: AND дал две и три записи, OR - пять и ноль; после восстановления AND снова получены две и три. Workflow не публиковался; старые схемы не изменялись. Реальная форма, CRM, рассылки, Cloud, сложные группы условий и Merge не тестировались. Обложка - редакционная иллюстрация.
Частые вопросы
Чем AND отличается от OR в n8n If?
AND требует выполнения всех условий. OR достаточно одного выполненного условия. В учебном наборе AND пропускает две записи, OR - все пять, поэтому результат проверяется не только по общему числу, но и по ID.
Почему false-ветка не означает ошибку workflow?
False означает, что запись не удовлетворяет выбранным условиям. Это нормальный результат проверки, который можно направить на ручную обработку. Техническая ошибка узла - другой случай: в этом примере она не обрабатывается через false.
Как не пропускать пустое сообщение из пробелов?
Проверьте, что message - строка, затем сравните длину message.trim() с нулём. Проверка типа нужна для null, отсутствующего поля и объектов. Сам trim() не оценивает содержание и не превращает сообщение в корректную заявку.
Почему обе ветки выполнились в одном запуске?
If проверяет каждый item отдельно. При пяти разных заявках две могут пройти условия, а три - нет. Тогда обе ветки получают разные записи. Для каждой отдельной записи в этом примере выбран один из двух выходов.
Нужно ли публиковать workflow для этой проверки?
Нет: используется Manual Trigger и кнопка Execute workflow. Публикация нужна для автоматического входа, например production Webhook или расписания. Перед такой заменой заново проверьте структуру данных и безопасность внешних действий.
