Ветка n8n исчезла после пустого результата: когда нужен Always Output Data

Автоматизация ищет клиента по номеру договора и должна сообщить сотруднику, если ничего не найдено. При совпадении всё работает, а при пустом поиске не приходит даже уведомление. Выполнение заканчивается без красной ошибки. Причина может быть в том, что поисковый узел вернул ноль элементов: следующему узлу просто нечего обрабатывать.

В n8n важно различать отсутствие элементов и один элемент с пустым содержимым. Пустой поток означает, что дальше по этой связи не переданы данные. Пустой объект всё ещё может быть отдельным элементом потока и запускать дальнейшую обработку. Настройка Always Output Data позволяет получить такой элемент после узла, который выполнился, но не вернул данных. Она полезна, когда отсутствие результата само должно стать событием.

Где включить продолжение

Откройте настройки именно поискового узла и включите Settings → Always Output Data. Затем выполните поиск по заведомо отсутствующему тестовому номеру и посмотрите выход. Ожидается пустой элемент вместо нуля элементов. Настройка не заставляет запускаться узел, который вообще не получил входа; искать её нужно на том шаге, где данные впервые исчезли.

Теперь появляется новая опасность: следующий узел записи может принять пустой элемент за клиента. Например, создать заявку без номера или отправить сообщение с незаполненным адресом. Поэтому сразу после поиска стоит превратить результат в явное решение. В нашем договоре найденный клиент обязательно имеет непустой строковый customerId. Всё остальное идёт в ветку «не найден» и не допускается до записи.

Превращаем отсутствие в данные

Добавьте после поиска Code node в режиме Run Once for All Items. Следующий код подходит для выхода, где каждый найденный клиент занимает собственный item и содержит строковое поле customerId. Если ваш узел возвращает внешний контейнер с массивом результатов, сначала разберите именно эту форму: один item с массивом отличается от нескольких клиентов на выходе.

return $input.all().map((item, index) => {
  const id = item.json.customerId;
  const found = typeof id === 'string' && id.trim().length > 0;
  return {
    json: found
      ? { found: true, customerId: id.trim() }
      : { found: false, reason: 'customer_not_found' },
    pairedItem: { item: index },
  };
});

Подключите IF node и сравните логическое поле found с true. К истинному выходу подключается дальнейшая работа с существующим клиентом, к ложному — уведомление о пустом поиске. Идентификатор для записи берётся из текущего customerId. В ложной ветке этого поля нет: случайный переход к записи должен быть дополнительно остановлен обязательной проверкой её входа.

Код сохраняет связь каждого результата со входным элементом через pairedItem. Это полезно для дальнейших выражений, но не восстанавливает бизнес-данные, которые поисковый узел уже отбросил. Если уведомлению нужен номер исходного договора, сохраните его отдельно до поиска и проверьте связь с конкретным запросом. Не берите первый договор из общего списка, когда в одном выполнении обрабатываются несколько клиентов.

Проверяем три разных выхода

Для первого случая подготовьте существующего клиента с заполненным номером. Выход нормализатора должен содержать found: true и тот же идентификатор. Для второго используйте отсутствующий номер: после включения настройки придёт пустой элемент, а нормализатор выдаст found: false. Третий случай — ноль элементов без включённой настройки: обработка по этой связи не дойдёт до нормализатора. Так становится видно, зачем настройка вообще понадобилась.

Отдельно передайте элемент с пустым номером или только с именем. Он тоже должен уйти в ветку отсутствия корректного клиента. После этого проверьте, что уведомление действительно отправляется один раз, а запись в рабочую систему не вызывается. Для испытаний используйте тестовый получатель и отдельное хранилище, чтобы проверить саму ветку, а не создавать настоящие заявки.

Не включайте настройку на каждом узле подряд. Условный шаг может начать выпускать пустой элемент в неожиданную ветку, а в цикле это способно нарушить условие завершения. В описании настроек узлов отдельно отмечена осторожность с IF. Сначала найдите границу исчезновения данных, затем добавьте продолжение и явную проверку содержимого.

В платном курсе «Продвинутый n8n» — откройте программу вы отработаете обработку данных и связь элементов между узлами, тестирование на подготовленных примерах и контролируемые сбои. Следующая задача после пустого поиска — проверить целую автоматизацию: правильный клиент, пустой результат и некорректная запись должны приводить к разным, заранее определённым действиям. Программа также охватывает API-интеграции и разделение больших процессов на дочерние workflow.