IF node в n8n ¶

Обновлено: 2026-05-29

IF node нужна для простого бинарного решения: условие истинно или ложно. Её сила — в ясной развилке, а не в сложной маршрутизации на десятки вариантов. Если workflow должен выбрать один из многих статусов, каналов или категорий, чаще подходит Switch; если нужно только отделить валидные записи от проблемных — IF остаётся самым понятным вариантом.

Когда использовать ¶

• нужно отделить валидные items от невалидных
• решение имеет две ветки: да/нет, прошло/не прошло, найдено/не найдено
• условие можно объяснить одной фразой владельцу процесса
• после проверки обе ветки должны быть видны в execution history

Настройка по шагам ¶

1. Перед IF приведите поля к стабильному типу: string, number, boolean или date.
2. Проверяйте не только значение, но и существование поля: missing field должен идти в управляемую ветку.
3. Назовите ноду по решению: “Оплата подтверждена?”, “Есть телефон?”, “Сумма выше лимита?”.
4. Разнесите независимые условия в несколько IF или подготовительный Code node с флагами.
5. После IF проверьте item count в true и false, чтобы не спутать фильтрацию с потерей данных.

Типичные ошибки ¶

• expression сравнивает строку "100" с числом 100 и даёт неожиданный результат
• false branch оставлена пустой, поэтому проблемные items исчезают без лога
• одна IF node проверяет и статус, и сумму, и источник, и наличие email одновременно
• ветки названы технически, и через месяц непонятно, какое бизнес-решение принималось

Проверка ¶

• Прогоните item с валидным полем, пустым полем, отсутствующим полем и неожиданным типом.
• Убедитесь, что false branch не теряется, а пишет причину skip/error.
• Проверьте expressions на реальном batch, не только на pinned data.
• Запишите в runbook условие, ожидаемые ветки и пример payload.

Как читать эту ноду в execution history ¶

Разбор IF node в n8n полезен только тогда, когда читатель понимает, что именно нода получает и что отдаёт дальше. В n8n всегда проверяйте input и output ноды рядом: количество items, имена полей, binary data, paired items и ошибки преобразования.

Роль ноды в архитектуре workflow ¶

Для IF node в n8n заранее назовите ноду по действию: “нормализовать лид”, “получить заказ”, “проверить дубль”, “ответить webhook”. Если название звучит как “тут вся логика”, ноду стоит разделить: отдельно сбор данных, отдельно проверка, отдельно действие.

• одна нода должна делать одно понятное действие
• после внешнего API нормализуйте response в стабильные поля
• сложные условия выносите в IF/Switch или Code node с тестовыми примерами
• после Merge/Loop/Code проверяйте item linking, иначе downstream expressions могут ломаться
• для production добавляйте owner, комментарий и ссылку на runbook или ошибку

Связанные материалы ¶

• Справочник нод

Практический минимум перед закрытием задачи ¶

• проверьте input и output ноды на одном item
• затем прогоните batch из нескольких items
• проверьте пустой input и missing field
• дайте ноде имя по роли, а не по типу

Шаблон записи в runbook ¶

Нода в n8n должна делать одну понятную вещь. Если внутри одной настройки одновременно фильтр, преобразование, бизнес-решение и fallback, такую логику трудно отлаживать и переносить между workflow.

Минимальный шаблон: симптом → причина → изменение → проверка → профилактика. Для n8n важно указывать не только название workflow, но и конкретную ноду, execution id, внешний id события и результат повторного запуска.

Когда не стоит усложнять workflow ¶

Не добавляйте AI, очередь, отдельную базу или сложный Code node, если проблема решается явной валидацией поля, простым IF/Switch, правильным credential или корректным retry. Чем меньше скрытой магии, тем легче поддерживать workflow через месяц.

Контрольные вопросы ¶

• Понятно ли, какая внешняя система, нода или настройка является источником проблемы?
• Есть ли минимальный тестовый payload, на котором можно повторить сценарий без production-риска?
• Описан ли безопасный rollback: что вернуть, если исправление ухудшит ситуацию?
• Есть ли ссылка на execution, лог или внешний объект, по которому другой человек сможет проверить вывод?

Эти вопросы нужны не для формальности. Они защищают n8n-хаб от абстрактных советов: каждая страница должна вести к наблюдаемому действию, измеримой проверке и понятной профилактике.

Практика использования ноды ¶

Страница IF node в n8n должна отвечать за поведение ноды, а не за полный бизнес-рецепт. Поэтому при внедрении фиксируйте вход, выход и изменение количества items.