Ошибка “Can’t determine which item to use” в n8n: причины и решение

Генератор выражений JSON для n8n

В системах автоматизации n8n ошибка “Can’t determine which item to use” возникает при неоднозначном выборе элемента входного массива или при некорректной работе с контекстом данных. Ниже представлены причины возникновения ошибки, архитектурные паттерны и практические рекомендации, актуальные для конфигураций 2024–2025 годов.

 

Почему n8n не может определить нужный JSON

1. Несколько входящих элементов (items)

Когда нода получает массив элементов, движок не знает, какой именно item использовать без явной индексации. Любые выражения, не указывающие item, приводят к неопределённости.

2. Неправильное использование выражений

Ошибка часто возникает при обращении к данным ноды напрямую:

{{ $node["SomeNode"].json.field }}

Если нода возвращает несколько элементов, выражение становится неоднозначным. Корректный вариант:

{{$item(0).$node["SomeNode"].json["field"]}}

3. Данные не переданы дальше по цепочке

После ветвлений или параллельных запросов данные могут отсутствовать в текущем $json. Если поле существует только в одной ветке, выражение перестаёт быть валидным.

Два надёжных паттерна работы с JSON в n8n

Подход A: протаскивание данных вперёд (Set / Function / Merge)

Идея

Все необходимые поля формируются сразу после получения данных. Далее workflow опирается только на актуальное содержимое $json.

Пример

return [{
  json: {
    entityId: data.id,
    phone: data.phone,
    status: data.status
  }
}];

В следующей ноде:

$json.contractId = contract.id ?? null;
$json.totalSum = contract.sum ?? null;

return [{ json: $json }];

Финальные выражения:

{{$json.entityId}}

{{$json.contractId}}

{{$json.totalSum}}

Преимущества

• минимизация ошибок выбора items;
• чистая структура данных;
• масштабируемая архитектура для больших схем;
• исключение чрезмерных обращений к $node[...].

Подход B: финальный агрегатор (Build Context)

Идея

Создаётся одна Function-нода, которая собирает все данные в единый объект. Все другие ноды используют только этот объект.

Пример

const sourceA = $item(0).$node["GetSourceA"].json;
const sourceB = $item(0).$node["GetSourceB"].json;

const result = {
  entityId: sourceA.id ?? null,
  phone: sourceA.phone ?? null,
  contractId: sourceB.contractId ?? null,
  amount: sourceB.amount ?? null
};

return [{ json: result }];

Далее выражения выглядят так:

{{$json.entityId}}

{{$json.contractId}}

Преимущества

• единая точка контроля данных;
• предсказуемость структуры JSON;
• упрощённая отладка и масштабирование.

Шпаргалка по выражениям n8n

Если поле уже есть в текущем item

{{$json.fieldName}}

Если данные берутся из другой ноды

{{$item(0).$node["NodeName"].json["fieldName"]}}

• всегда указывается item(0);
• для имён полей используются квадратные скобки;
• сложная логика выносится в Function-ноды.

Почему нельзя писать $node["Node"].json.field

Если нода возвращает массив, движок не может выбрать элемент. Возникает ошибка выбора item.

Как избежать ошибок при написании выражений

Оптимальным способом считается использование встроенного генератора выражений:

1. открыть редактор выражений;
2. перейти во вкладку Nodes;
3. выбрать ноду и поле;
4. использовать сгенерированное выражение.

Лучшие практики для будущих воркфлоу

1. Стандартизировать имена нод

Рекомендуемые варианты:

• GetSourceData
• FetchContract
• BuildContext
• SendNotification

2. Принять архитектурное правило

Используется один подход:

• либо протаскивание $json вперёд;
• либо финальный агрегатор.

Смешивание приводит к неопределённости данных.

3. Минимизировать использование $node[...]

Обращения к другим нодам концентрируются в одной Function-ноде. Это снижает риск ошибок и улучшает читаемость схемы.

Заключение

Ошибка «Can’t determine which item to use» указывает на неопределённость структуры данных в workflow. При использовании единых архитектурных правил, работе через $json и контроле источников данных проблема полностью устраняется и обеспечивает стабильную, production-ready автоматизацию.