---
title: "IF, Switch и Filter в n8n: условия и чистка — Nodbot"
source_url: "https://nodbot.ru/nodes/if-switch-filter/"
canonical_url: "https://nodbot.ru/nodes/if-switch-filter/"
language: "ru"
content_type: "KnowledgePage"
section: "nodes"
generated_at: "2026-05-30"
word_count_source: 979
---

# IF, Switch и Filter в n8n: условия и чистка чистка данных

## AI summary

Как выбрать IF, Switch или Filter в n8n: условия, несколько веток, фильтрация items, expressions, empty output, Merge и типовые ошибки логики.

## Best used for

Страница объясняет «IF, Switch и Filter в n8n: условия и чистка — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Чем отличаются IF, Switch и Filter
- IF: простое ветвление «да/нет»
- Switch: несколько маршрутов вместо цепочки IF
- Filter: убрать мусор до дорогих действий
- Как строить условия без хрупких expressions
- Merge после условий
- Типовые ошибки
- Практический пример: лид из формы

## Source outline

# IF, Switch и Filter в n8n: условия и чистка чистка данных

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

Условия в n8n чаще всего строятся на трёх нодах: IF, Switch и Filter. Они похожи, но решают разные задачи. IF делит поток на две ветки, Switch отправляет items по нескольким маршрутам, а Filter оставляет только те items, которые прошли проверку. Если перепутать эти роли, workflow быстро превращается в набор случайных веток, где часть данных теряется, а часть уходит не туда.

Быстрый выбор

IF — когда есть «да/нет». Switch — когда вариантов больше двух: новый лид, повторный лид, VIP, спам. Filter — когда нужно выбросить лишние items и оставить только подходящие записи для следующих нод.

## Чем отличаются IF, Switch и Filter

- Нода | Что делает | Когда брать | Типичная ошибка
- IF | делит поток на true/false | проверка одного условия или группы условий | использовать для 5–7 вариантов, когда нужен Switch
- Switch | отправляет item в один из нескольких outputs | маршрутизация по статусу, источнику, типу события | не задать fallback для неизвестного значения
- Filter | пропускает только подходящие items | очистка списка перед обработкой | ждать отдельную false-ветку, которой у Filter нет

## IF: простое ветвление «да/нет»

IF удобен для сценариев, где нужно принять одно бинарное решение: есть телефон или нет, сумма больше 10 000 или меньше, источник равен tilda или нет, заявка уже есть в CRM или её нужно создать. Важно заранее нормализовать данные: телефон привести к одному формату, email — к нижнему регистру, пустые значения — к null или пустой строке.

```
{{ $json.phone && $json.phone.replace(/\D/g, '').length >= 10 }}
```
После IF не забывайте, что downstream-нода получает items только из выбранного output. Если нужно снова объединить ветки, используйте Merge, но сначала проверьте, что обе ветки возвращают совместимые поля.

## Switch: несколько маршрутов вместо цепочки IF

Switch лучше, когда вариантов больше двух. Например, webhook получает события lead.created , lead.updated , payment.succeeded , payment.canceled . Делать цепочку из пяти IF можно, но поддержку такого workflow быстро станет сложно вести. В Switch каждый case читабелен, а отдельный fallback помогает поймать неизвестные события.

```
{
  "event_type": "lead.created",
  "source": "tilda",
  "lead_id": "lead_1001"
}
```
Для российских интеграций Switch особенно полезен в связках «Tilda → CRM», «ЮKassa → заказ», «VK Lead Forms → менеджер». Один webhook может принимать разные события, а Switch разводит их по понятным веткам.

## Filter: убрать мусор до дорогих действий

Filter не маршрутизирует данные по нескольким веткам. Он просто оставляет только те items, которые подходят под условие. Это удобно перед HTTP Request, AI Agent, отправкой письма или созданием сделки в CRM. Если из 500 строк Google Sheets только 17 требуют обработки, сначала отфильтруйте их, а потом запускайте дорогие или лимитированные действия.

Хорошее правило: Filter должен стоять до внешних API и AI-запросов, если часть items заведомо не нужна. Так workflow становится дешевле, быстрее и меньше упирается в лимиты.

## Как строить условия без хрупких expressions

- Не пишите длинные выражения прямо в IF, если их трудно читать. Вынесите подготовку в Set/Edit Fields или Code node.
- Создайте поле normalized_status , contact_key , event_type до ветвления.
- Проверяйте пустые значения явно: телефон, email, ID сделки, ID заказа.
- Не сравнивайте телефоны и даты в сыром виде, сначала нормализуйте формат.
- Оставляйте fallback-ветку для неизвестного статуса или события.

## Merge после условий

Merge нужен, когда после разных веток workflow должен снова перейти к общей логике: записать результат в таблицу, отправить один формат уведомления или вернуть HTTP-ответ. Но Merge не должен маскировать разный контракт данных. Если одна ветка возвращает deal_id , а другая error_message , лучше привести их к единой структуре до объединения.

```
{
  "result": "created",
  "entity": "deal",
  "entity_id": "12345",
  "source_event": "lead.created"
}
```

## Типовые ошибки

- Симптом | Причина | Что сделать
- после IF дальше ничего не происходит | item ушёл в другую ветку или output пустой | открыть execution и посмотреть, какой output сработал
- Switch не ловит значение | разный регистр, пробелы, другое имя поля | нормализовать поле перед Switch
- Filter удалил все items | условие слишком строгое или поле отсутствует | добавить Set/Edit Fields и проверить входные данные
- после Merge поля пропали | ветки возвращают разные структуры | привести выходы веток к одному контракту
- workflow трудно читать | слишком много IF подряд | заменить на Switch или вынести правила в Code node

## Практический пример: лид из формы

- Webhook принимает заявку.
- Set/Edit Fields создаёт contact_key , source , lead_type .
- IF проверяет, есть ли телефон или email.
- Switch выбирает маршрут: Битрикс24, amoCRM, Google Sheets или Telegram.
- Filter отбрасывает тестовые заявки и внутренние домены.
- Merge возвращает общий результат для ответа webhook.

## Проверка ноды на реальных items

Ноду или паттерн «IF, Switch и Filter в n8n» лучше проверять не на одном item, а на наборе входов: пустой объект, массив из нескольких items, неожиданный тип поля и повтор события. Так вы увидите, где ломается mapping ещё до подключения реального API.

Для этой страницы базовый источник данных: входной item по теме «IF, Switch и Filter в n8n»: источник события, внешний ID, время получения и нормализованные поля. Если нода меняет внешнюю систему, добавьте dry-run или review-ветку.

- Слой | Что зафиксировать | Зачем
- Вход | входной item по теме «IF, Switch и Filter в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам
- Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «IF, Switch и Filter в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}
```

### Критерий готовности

- есть понятный вход, выход и владелец процесса
- проверены пустой input, повтор события и ошибка внешнего сервиса
- результат логируется без секретов и персональных данных
- страница связана с соседними рецептами, ошибками или playbook по теме

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

- Set/Edit Fields — нормализация полей перед условиями.
- Merge — объединение веток.
- Webhook — входящие события.
- Диагностика Webhook — если данные не доходят до условий.

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)
- [Сравнения](/compare/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.