Если обращение нужно направить в один из трёх отделов, цепочка из нескольких If быстро становится неудобной. В этой инструкции настроим один Switch: запросы на покупку попадут в продажи, вопросы по работе сервиса - в поддержку, вопросы о счёте - в бухгалтерию. Всё, что не подошло, останется в отдельной ветке проверки.
Результат инструкции
Вы получите ручной workflow из восьми узлов. Пять вымышленных обращений разделятся так: A1 → Sales Queue, A2 и A5 → Support Queue, A3 → Billing Queue, A4 → Manual Review. В результате каждого конечного узла появится поле queue; исходные ID, тип обращения и сообщение сохранятся.
Это проверка маршрутизации, а не готовая интеграция с отделами: схема не создаёт тикеты, не отправляет письма и не пишет в CRM. Названия Queue обозначают выходные ветки внутри n8n. Модель не используется. Switch сравнивает поле request_type, а не читает смысл сообщения и не угадывает отдел.
Что понадобится
- Запущенный n8n с возможностью создать новый workflow. Пример проверен на версии 2.42.4.
- Отдельный пустой холст: рабочие схемы с внешними действиями не меняйте.
- JSON из шага 2. API-ключи, платная модель и аккаунты CRM для упражнения не нужны.
Установка n8n локально через Docker
Шаг 1. Создайте отдельный workflow
Откройте Overview → Create workflow. Начните с пустого холста. В учебной схеме используется Manual Trigger: запускать её будем кнопкой Execute workflow, без Publish. Так изменение правил не затронет реальные обращения.
Шаг 2. Импортируйте готовый JSON
Скачать n8n-switch-routing-demo.json
Откройте файл, скопируйте весь JSON, щёлкните свободную область пустого холста и нажмите Ctrl+V. Появятся восемь узлов и имя ezgpt-switch-routing-demo. Нажмите Zoom to Fit. Если в вашей версии удобнее импорт из файла, используйте More actions → Import from File.
Основная цепочка: Manual Trigger → Test Requests → Split Requests → Route Request. У Route Request четыре подписанных выхода: sales, support, billing, review. Они подключены соответственно к Sales Queue, Support Queue, Billing Queue и Manual Review. Не вставляйте JSON второй раз поверх уже добавленных узлов.
n8n: импорт и экспорт workflow
Шаг 3. Проверьте тестовые обращения
Дважды щёлкните значок Test Requests. Это Edit Fields, Mode = JSON Output. Поле JSON содержит объект с массивом requests:
{
"requests": [
{
"id": "A1",
"request_type": "sales",
"message": "Нужен расчёт проекта"
},
{
"id": "A2",
"request_type": "support",
"message": "Не открывается кабинет"
},
{
"id": "A3",
"request_type": "billing",
"message": "Нужна копия счёта"
},
{
"id": "A4",
"request_type": "other",
"message": "Предложение о сотрудничестве"
},
{
"id": "A5",
"request_type": " SUPPORT ",
"message": "Не получается войти"
}
]
}Нажмите Execute step. Получится один item, внутри которого пять обращений. request_type - строковый код категории, message - текст, id - метка для сверки. A5 намеренно содержит пробелы и заглавные буквы. A4 содержит неизвестный код other: его нельзя терять.
Именно request_type задаёт направление. Если написать в message «Нужен счёт», но оставить request_type = sales, схема всё равно выберет продажи. Автоматическое определение категории по тексту - отдельная задача, в этот пример оно не входит.
Шаг 4. Разделите массив перед Switch
Откройте Split Requests - узел Split Out. Fields To Split Out = requests, Include = No Other Fields. Destination Field Name в Options не задан. Выполните Execute step: теперь в OUTPUT должно быть пять items, каждый с полями id, request_type и message.
Если оставить массив внутри одного item, Switch не распределит пять обращений по отдельности. Если задать Destination Field Name, поля окажутся внутри обёртки и выражение из следующего шага потребует другого пути. Для повторения примера оставьте настройки из файла.
Как разделить JSON-массив через Split Out
Шаг 5. Проверьте три правила маршрутизации
Откройте Route Request - узел Switch. Mode = Rules. Разверните Routing Rule 1. Левое значение в режиме Expression содержит:
{{ typeof $json.request_type === 'string' ? $json.request_type.trim().toLowerCase() : '' }}Тип сравнения String, оператор is equal to. Правое значение в режиме Fixed = sales. Rename Output включён, Output Name = sales. Во втором правиле такое же выражение и оператор, но правое значение и Output Name = support. В третьем - billing.
Если создаёте правила вручную, добавляйте следующие через Add Routing Rule. Проверьте не только подписи выходов, но и правые значения условий: переименование выхода само по себе не меняет проверку. В нашем файле порядок: sales, support, billing.
Convert types where required оставьте выключенным. Выражение уже возвращает строку: для неправильного типа оно вернёт пустую строку, которая не равна ни одному коду отдела. Это техническое значение для сравнения; исходный request_type не перезаписывается.
Шаг 6. Настройте резервную ветку
В Options у Route Request проверьте Fallback Output = Extra Output и Rename Fallback Output = review. Это четвёртый выход, соединённый с Manual Review. Именно туда должен попасть A4, потому что other не совпадает ни с одним правилом.
Вариант None (default) не создаёт резервную ветку: неизвестная запись не появится ни на одном выходе. Для этого упражнения он не подходит. Переименование резервного выхода без выбора Extra Output не заменяет настройку Fallback.
Ignore Case выключен: приведение к нижнему регистру уже выполняется в выражении. Send data to all matching outputs тоже выключен. Пока нам нужен один маршрут на обращение, а не несколько действий для одной записи.
Шаг 7. Проверьте поля конечных узлов
Sales Queue - это Edit Fields, Mode = Manual Mapping. В Fields to Set одно строковое поле queue со значением sales в режиме Fixed. Include Other Input Fields включён. В Support Queue значение queue = support, в Billing Queue = billing, в Manual Review = manual_review.
В каждом конечном узле включено сохранение остальных входных полей. Если его выключить, останется только queue и вы не сможете понять, какое обращение куда попало. В Settings не включайте Execute Once: Support Queue должен обработать две записи, а не одну.
Здесь не создаётся постоянная очередь в базе. Поле queue видно в результате выполнения n8n. После отладки его можно использовать для следующего узла своей интеграции, но сам этот шаг ничего не отправляет.
Шаг 8. Запустите всю цепочку и сверяйте ID
Закройте настройки узла и нажмите Execute workflow на холсте. Откройте Route Request → OUTPUT. Вкладки должны показывать Sales - один item, Support - два, Billing - один, Review - один. Проверьте не только числа, но и записи:
- Sales: A1.
- Support: A2 и A5.
- Billing: A3.
- Review: A4.
Откройте Manual Review → OUTPUT → JSON. В нашем проверенном выполнении получен объект:
{
"id": "A4",
"request_type": "other",
"message": "Предложение о сотрудничестве",
"queue": "manual_review"
}queue добавил конечный Edit Fields, а не Switch. В четырёх конечных результатах должно быть пять записей суммарно, каждая с исходным ID и ровно в одном месте. Если A4 отсутствует, вернитесь к настройке Fallback и соединению review.
Шаг 9. Проверьте пробелы и регистр
Откройте Support Queue → OUTPUT → JSON и найдите A5. Исходное request_type по-прежнему равно " SUPPORT ", но queue равно support. Это нормально: для сравнения мы удаляем пробелы по краям и меняем регистр, а входные данные сохраняем.
Если нужно сохранить нормализованный код отдельным полем, добавьте отдельный Edit Fields перед Switch. В этой схеме его нет. Не заменяйте выражение просто на $json.request_type, если хотите повторить результат A5: без нормализации пробелы изменят сравнение.
Шаг 10. Проверьте отсутствующие поля и неверные типы
В Test Requests временно замените JSON следующим набором. Правила Switch оставьте исходными:
Показать код (36 строк)
{
"requests": [
{
"id": "E1",
"message": "Тип отсутствует"
},
{
"id": "E2",
"request_type": null
},
{
"id": "E3",
"request_type": 42
},
{
"id": "E4",
"request_type": {
"value": "sales"
}
},
{
"id": "E5",
"request_type": [
"sales"
]
},
{
"id": "E6",
"request_type": "\t\n "
},
{
"id": "E7",
"request_type": "SUPPORT"
}
]
}Запустите весь workflow. В Support Queue должна попасть только E7; в Manual Review - E1, E2, E3, E4, E5 и E6. Sales Queue и Billing Queue новых записей не получают. Ошибки trim() быть не должно: проверка typeof не даёт вызвать её на числе, массиве, объекте или null.
Пустой тип не превращается в sales и не удаляется. Он уходит на проверку, как неизвестный код. При этом схема не проверяет полноту обращения: например, отсутствие message само по себе не меняет маршрут, если request_type корректен. Обязательные поля проверяйте отдельным шагом.
Шаг 11. Проверьте пересечение правил
Верните исходный JSON из шага 3. В Route Request временно поменяйте только правое значение второго правила с support на sales; Output Name оставьте support, чтобы выходы не переименовывались. Теперь первое и второе правила совпадают для A1.
Сначала оставьте Send data to all matching outputs выключенным и выполните всю цепочку. A1 попадёт только в Sales Queue: сработало первое совпадение. Support Queue новых данных не получит; A2, A4 и A5 уйдут в Manual Review, потому что правила для support сейчас нет. Billing Queue получит A3.
Затем включите Send data to all matching outputs и повторите полный запуск. A1 окажется и в Sales Queue, и в Support Queue. Вместе с A3 и тремя записями проверки сумма выходных записей станет шесть, хотя исходных обращений пять. Это намеренное повторное направление, а не новая заявка.
В конце верните правое значение второго правила на support и выключите Send data to all matching outputs. Не подключайте к этому тесту отправку сообщений: пересечение правил могло бы вызвать несколько отправок для одного обращения. Старый OUTPUT узла, не участвовавшего в новом запуске, не считайте новым результатом.
Шаг 12. Проверьте пустой вход и восстановите схему
Для последней проверки в Test Requests поставьте:
{"requests":[]}Выполните весь workflow. Split Requests вернёт ноль items; Route Request и конечные узлы для этого запуска не выполнятся. Пустой список - отсутствие обращений, а не одна запись для Manual Review. Не включайте Always Output Data ради появления строки: это изменит поведение.
Теперь верните JSON из шага 3, три разных правила и исходные Options из шага 6. Снова выполните цепочку. Проверьте A1 → sales, A2/A5 → support, A3 → billing, A4 → manual_review и сохранение исходных полей. Это завершённый результат упражнения. Workflow остаётся ручным и неопубликованным.
Если результат отличается
| Симптом | Что проверить | Исправление |
|---|---|---|
| A4 не виден на выходах | Fallback и соединение review | Extra Output → Manual Review |
| A5 попал в review | Левое выражение правила | Проверка типа, trim, toLowerCase |
| Все обращения идут одним item | Split Requests перед Switch | Разделить массив requests |
| Один ID в нескольких ветках | Совпадения и Options | Выключить все совпадения |
| В результате только queue | Конечные Edit Fields | Include Other Input Fields |
| Старые данные в пустой ветке | Результат нового выполнения | Сверять OUTPUT Switch и запуск |
Перед подключением реальных обращений
Заменяйте учебный вход только после проверки его структуры. Если Webhook получает JSON в body, поле может находиться в $json.body.request_type, а не на верхнем уровне. Если каждое обращение уже отдельный item, Split Out не понадобится. Сначала проверьте один вымышленный запрос без внешних действий.
Как принять JSON через Webhook
Как проверить обязательные условия через If
Значение request_type от пользователя - не доказательство его полномочий. Нельзя по одному слову billing разрешать платёж, возврат или доступ к бухгалтерским документам. Сначала нужна проверка прав и данных, а перед значимыми действиями - подтверждение человеком.
Резервный выход ловит отсутствие совпадения с правилами, но не заменяет обработку технических ошибок API. Для настоящей CRM понадобятся ключи, права, журнал результата и защита от повторных отправок. Здесь проверен только маршрут внутри n8n; интеграции с отделами нет.
Что проверено редакцией
9 октября 2026 года схема проверена на n8n 2.42.4. Шесть CLI-сценариев в отдельной тестовой базе: исходный набор, семь записей с пограничными типами, пересечение правил с первым совпадением и со всеми совпадениями, пустой массив и восстановление. Проверены ID, поля queue и сохранение исходных данных. В локальном редакторе выполнены исходный набор, оба режима пересечения и восстановление: результаты совпали. Новый workflow не публиковался, старые схемы не менялись. Реальные формы, CRM, отправки, Cloud, режим Expression и технические ошибки API не тестировались. Обложка - редакционная иллюстрация.
Частые вопросы
Чем Switch отличается от If в n8n?
If удобно использовать для двух результатов проверки: true и false. В этом упражнении Switch распределяет обращения по трём значениям поля и отдельно сохраняет неизвестные типы. Он не определяет категорию по смыслу сообщения.
Почему неизвестное обращение исчезло после Switch?
Проверьте Fallback Output и подключение резервной ветки. В нашем примере стоит Extra Output, выход review связан с Manual Review. При None записи без совпадения не появляются на выходах.
Может ли один item попасть в две ветки?
Да. В проверенном примере при пересечении двух правил и включённых всех совпадениях A1 попал в обе ветки. Для одного маршрута оставьте Send data to all matching outputs выключенным и проверьте порядок правил.
Почему SUPPORT с пробелами попадает в поддержку?
Левое выражение проверяет тип, убирает пробелы по краям и приводит строку к нижнему регистру. Для сравнения получается support. Исходное поле при этом не меняется; выбранный маршрут записывается в queue конечного узла.
Нужны ли AI-модель и публикация workflow?
Нет. Это ручное упражнение с заранее заданными кодами категорий: достаточно Execute workflow. Автоматический вход через Webhook или расписание и определение категории моделью требуют отдельной настройки и новых проверок.
