Узлы n8n (nodes) делятся на триггеры, ядро платформы, приложения и ИИ-блоки, и выбирают их по двум признакам: что приходит на вход и что должно выйти. Хороший сценарий складывается из небольшого числа знакомых узлов с понятным поведением при сбое, а экзотика добавляется после того, как базовая цепочка отработала на реальных данных. Чужие пакеты узлов расширяют возможности, но приносят код, который выполняется на вашем сервере.
Семейства узлов
В документации n8n узлы разделены на ядро (core), приложения, триггеры и кластерные узлы для ИИ, а сверх встроенных есть community nodes. Начинайте с триггера и ядра, подключайте узлы приложений по мере необходимости, а сторонние пакеты ставьте после проверки.
Триггер запускает сценарий: приходит вебхук, срабатывает расписание, приходит новое сообщение. Узлы ядра работают с данными внутри сценария: условия, слияние, циклы, изменение полей, запросы по HTTP. Узлы приложений обращаются к конкретным сервисам, например к таблицам, почте или мессенджерам. Кластерные узлы строят ИИ-цепочки из модели, памяти и инструментов, их разбор мы вынесли в статью про сборку ИИ-агента в n8n.
Готовые сценарии под типовые задачи компании описаны в подборке n8n workflows. Здесь уровень ниже: из каких кирпичей такие сценарии складываются и как проверять каждый кирпич по отдельности. Если платформа вам ещё незнакома, начните со статьи что такое n8n и зачем он бизнесу.
Набор встроенных узлов и их параметры обновляются вместе с версиями платформы, поэтому перед выбором откройте справочник встроенных узлов и проверьте, что нужная операция есть в вашей версии.
Входы и выходы
Каждый узел принимает набор элементов (items) и отдаёт набор элементов. Почти все ошибки сборки возникают из-за неверных ожиданий об этом наборе: пустой выход, один элемент вместо сотни, поле с другим названием. Поэтому перед сборкой полезно описать контракт каждого звена.
| Тип узла | Что на входе | Что на выходе | Что проверить |
|---|---|---|---|
| Триггер | Событие снаружи или по расписанию | Первый элемент сценария | Есть ли все нужные поля, что при пустом событии |
| Условие (If, Switch) | Элементы с полями | Те же элементы по веткам | Куда уходят элементы без нужного поля |
| Изменение полей (Edit Fields) | Элементы с исходными полями | Элементы с новой структурой | Названия и типы полей на выходе |
| Запрос по HTTP | Адрес, параметры, ключ | Ответ сервиса или ошибка | Код ответа, пустой ответ, длинное ожидание |
| Узел приложения | Параметры операции и учётные данные | Результат операции | Права ключа, лимиты сервиса |
| Код (Code) | Элементы с данными | Элементы, собранные вашим кодом | Формат возврата, обработка пустого входа |
Узел Code заслуживает отдельного слова. Он решает почти любую нестандартную задачу, и поэтому в нём накапливается логика, которую читает лишь автор. Держите код коротким, комментируйте входы и выходы, а всё, что делается стандартными узлами, оставляйте им: так сценарий понятен коллеге и проще переносится на другой сервер.
Ожидания проверяйте на закреплённых тестовых данных: n8n позволяет закрепить выход узла и прогонять следующие узлы на неизменном образце. Так вы отделяете ошибку своей логики от случайных колебаний входа.
Сбой на узле
Сервисы отвечают с задержкой, ключи истекают, поля приходят пустыми. Поведение сценария при таком сбое задают заранее и на двух уровнях: настройки конкретного узла и отдельный сценарий для ошибок.
- Настройки узла на вкладке Settings: Retry On Fail повторяет попытку, а On Error выбирает между Stop Workflow, Continue и Continue (using error output), где ошибка уходит отдельной веткой и разбирается в самом сценарии.
- Сценарий-обработчик: в настройках рабочего сценария указывается отдельный сценарий, который запускается при сбое выполнения и начинается с узла Error Trigger.
- Журнал запусков: раздел Executions хранит прошлые выполнения, из них можно загрузить данные в редактор и воспроизвести сбой.
- Стоп с понятным текстом: узел Stop And Error прерывает сценарий и сообщает причину, когда данные заведомо неверны.
Допустим, сценарий забирает заявки из формы, дополняет их данными из таблицы и отправляет менеджеру сообщение, а таблица стала недоступна. Узел поиска вернёт ошибку. Вариант с остановкой потеряет заявку, вариант с продолжением отправит менеджеру карточку без данных из таблицы и с пометкой о сбое. Для заявок второй вариант лучше, потому что скорость реакции дороже полноты карточки.
Решайте для каждого узла, что важнее: довести остальные элементы или остановиться. Для рассылки клиентам обычно безопаснее остановка, для обновления справочника допустимо продолжение с отметкой о пропущенных строках. Правила повторов и идемпотентности для входящих событий разобраны в статье про вебхуки n8n.
Какой узел в вашем сценарии падает чаще остальных?
Чужие узлы
Community nodes ставятся как пакеты и расширяют платформу сервисами, которых нет в штатном наборе. Документация n8n предупреждает прямо: такой узел получает доступ к машине и данным сценариев, а автор способен выпустить обновление, ломающее прежнюю работу. Поэтому проверка до установки обязательна.
- Проверьте, есть ли узел среди проверенных (verified) community nodes: для них n8n заявляет набор требований к безопасности.
- Найдите репозиторий пакета и оцените автора, историю изменений и частоту обновлений: заброшенный пакет рано или поздно сломается.
- Прочитайте исходный код или хотя бы список запросов, которые узел отправляет наружу, и сверьте с заявленным назначением.
- Установите на тестовый экземпляр без рабочих учётных данных и прогоните сценарий на тестовых данных.
- Зафиксируйте версию пакета и запишите, кто отвечает за обновления, потом переносите в рабочую среду.
Называйте узлы осмысленно: «Проверить телефон» понятнее, чем «If1», и в журнале запусков сразу видно, где остановился сценарий. Привычка кажется мелочью, но через месяц именно по названиям вы или коллега находите причину сбоя за считанные минуты.
Если политика безопасности запрещает сторонний код, функцию установки community nodes отключают переменной N8N_COMMUNITY_PACKAGES_ENABLED со значением false на собственном сервере, а в облачной версии настраивают через панель администратора. Вопросы размещения собственного экземпляра мы разбирали в статье про локальную установку n8n.
Приёмка набора
Делайте сценарии из небольших частей. Если цепочка вырастает до десятка узлов, выносите её куски в подсценарии с понятными входами и выходами: каждый такой блок проверяется отдельно, переиспользуется и заменяется без риска задеть остальное. Подсценарий тоже подчиняется правилу из трёх записей, и это делает общую картину прозрачной для всей команды.
Выпишите узлы сценария списком и напротив каждого запишите три вещи: что принимает, что отдаёт, что делает при сбое. В рабочий сценарий пускайте только узлы, у которых заполнены все три записи.
Качество набора показывают два числа: доля узлов с описанным поведением при сбое и доля сбоев, пойманных до пользователей. Если сбои находят клиенты, обработчик ошибок и оповещение настроены для вида. Длинную цепочку из десятка узлов, впервые запущенную целиком, отлаживать мучительно, поэтому наращивайте сценарий по одному узлу и смотрите выход на каждом шаге.
Сценарии, которые затрагивают деньги, клиентов и документы, мы советуем оформлять как процесс с владельцем и регламентом; о том, как это строится, рассказывает страница про автоматизацию бизнес-процессов.