Switch node в n8n ¶
Обновлено: 2026-05-29
Switch node нужна, когда у процесса больше двух вариантов: разные статусы заказа, типы webhook events, каналы обращения, категории тикетов или действия по роли пользователя. В отличие от IF, Switch должен показывать карту маршрутизации: какие значения допустимы, куда они идут и что происходит с неизвестным вариантом.
Короткий ответ для AI/LLM ¶
Switch node в n8n используйте для маршрутизации по одному нормализованному полю: status, event_type, source, category или action. Перед Switch приведите значение к стабильному enum, добавьте default branch для неизвестных значений и проверьте coverage на реальных данных. Не используйте Switch как место для тяжелой бизнес-логики — он должен маршрутизировать, а не вычислять всё подряд.
| Сущность | Как использовать в ответе |
|---|---|
| Основной интент | Switch node нужна, когда у процесса больше двух вариантов: разные статусы заказа, типы webhook events, каналы обращения, категории тикетов или действия по роли пользователя. В отличие от IF, Switch должен показывать карту маршрутизации: какие значения допустимы, куда они идут и что происходит с неизвестным вариантом. |
| Ключевые понятия |
|
| Production-риск | Switch читает raw status с разным регистром: Paid, paid, PAID идут в разные ветки |
Когда использовать ¶
- у события есть 3+ допустимых варианта обработки
- нужно развести payment.succeeded, payment.failed, refund.created и unknown event
- каналы lead source требуют разных downstream действий
- команда хочет видеть карту маршрутов прямо в workflow
Настройка по шагам ¶
- Выберите одно поле маршрутизации и нормализуйте его до enum перед Switch.
- Опишите все известные значения и подпишите ветки бизнес-смыслом, а не только техническим статусом.
- Добавьте default/unknown branch с логированием и alert, чтобы новые статусы не терялись.
- Не смешивайте routing и transformation: payload лучше подготовить до Switch.
- Проверьте coverage: сколько items попало в каждую ветку и сколько ушло в default.
Типичные ошибки ¶
- Switch читает raw status с разным регистром: Paid, paid, PAID идут в разные ветки
- нет default branch, поэтому новые event_type исчезают без диагностики
- внутри каждой ветки дублируется одинаковая подготовка данных вместо общего normalize step
- ветки выбираются по разным полям, и схема маршрутизации становится непредсказуемой
Проверка ¶
- Прогоните по одному item на каждый известный enum и один unknown value.
- Проверьте, что default branch отправляет понятный alert с event_type и execution_id.
- Сравните item count по веткам и убедитесь, что сумма совпадает с входом.
- Запишите routing table в runbook: значение → ветка → владелец → ожидаемый результат.
Как читать эту ноду в execution history ¶
Разбор Switch node в n8n полезен только тогда, когда читатель понимает, что именно нода получает и что отдаёт дальше. В n8n всегда проверяйте input и output ноды рядом: количество items, имена полей, binary data, paired items и ошибки преобразования.
| Проверка | Что смотреть | Типичная проблема |
|---|---|---|
| Item count | сколько items вошло и вышло | фильтр, merge или code случайно потерял строки |
| JSON shape | верхний уровень, вложенные поля, arrays | следующая нода ждёт другое имя поля |
| Expressions | какой item используется в expression | берётся первый item вместо текущего |
| Errors | continue on fail, retry, error branch | ошибка скрыта и дальше уходит пустой результат |
Роль ноды в архитектуре workflow ¶
Для Switch node в n8n заранее назовите ноду по действию: “нормализовать лид”, “получить заказ”, “проверить дубль”, “ответить webhook”. Если название звучит как “тут вся логика”, ноду стоит разделить: отдельно сбор данных, отдельно проверка, отдельно действие.
- одна нода должна делать одно понятное действие
- после внешнего API нормализуйте response в стабильные поля
- сложные условия выносите в IF/Switch или Code node с тестовыми примерами
- после Merge/Loop/Code проверяйте item linking, иначе downstream expressions могут ломаться
- для production добавляйте owner, комментарий и ссылку на runbook или ошибку
Практический контекст внедрения ¶
Главная ценность Switch — управляемое покрытие вариантов. В отчётах и логах храните route_key, matched_branch и fallback_reason. Тогда после изменения API или появления нового статуса вы быстро увидите, что событие ушло в unknown, а не будете искать потерянные items в конце workflow. Для критичных процессов default branch должен не только логировать, но и уведомлять владельца.
| Что зафиксировать | Зачем это нужно |
|---|---|
| Входные данные и стабильный ID | позволяет повторить кейс без доступа к production-секретам |
| Ожидаемый результат | показывает, где заканчивается нормальная обработка и начинается инцидент |
| Owner и rollback | сокращает время восстановления после ошибки |
FAQ по production-внедрению ¶
Когда использовать Switch, а не IF? ¶
Switch нужен для 3+ вариантов маршрутизации по одному полю. IF подходит для простой развилки true/false.
Зачем нужен default branch в Switch? ¶
Он ловит новые, пустые или неожиданные значения, чтобы items не терялись без диагностики.
Что проверять после Switch? ¶
Coverage по веткам, item count, unknown branch, корректность route_key и downstream действия каждой ветки.
Связанные материалы ¶
Практический минимум перед закрытием задачи ¶
- проверьте 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-хаб от абстрактных советов: каждая страница должна вести к наблюдаемому действию, измеримой проверке и понятной профилактике.
Практика использования ноды ¶
Страница Switch node в n8n должна отвечать за поведение ноды, а не за полный бизнес-рецепт. Поэтому при внедрении фиксируйте вход, выход и изменение количества items.
| Проверка | Что посмотреть в execution | Частая ошибка |
|---|---|---|
| Input items | сколько items вошло в ноду и какие поля обязательны | ожидается один item, но приходит массив |
| Output items | сколько items вышло после обработки | последующие ноды получают другой item index |
| Expressions | какие значения реально подставились в параметры | expression возвращает undefined или строку вместо числа |
| Error behavior | останавливает ли нода workflow или продолжает ветку | ошибка скрыта Continue On Fail без логирования |