n8n Data Table: Nach dem Lookup passt .item nicht mehr?

Ein Workflow liest mehrere Vorgänge ein und sucht zu jedem einen Eintrag in einer n8n Data Table. Anschließend scheitert ein Ausdruck mit .item, oder Daten landen beim falschen Vorgang. Besonders tückisch ist ein Lauf, der nur teilweise passende Tabellenzeilen findet: Die Anzahl der Ergebnisse stimmt dann nicht mehr mit der ursprünglichen Eingabemenge überein.

Warum ein Lookup die Zuordnung verändern kann

Ein Bericht für n8n 2.41.6 beschreibt genau diese Kombination mit „Get row(s)“ und „Always Output Data“. Q1 n8n dokumentiert, dass .item eine nachvollziehbare Zuordnung zum früheren Element benötigt; fehlende oder mehrdeutige Verbindungen können fehlschlagen. Q2 Die Data-Table-Operation „Get“ liefert passende Tabellenzeilen. Eine Existenzprüfung kann dagegen mit den dafür vorgesehenen Operationen aufgebaut werden. Q3

Damit ist noch kein genereller Produktfehler bewiesen. Zuerst muss geklärt werden, ob der Workflow eine Zeile anreichern, einen vorhandenen Vorgang auswählen oder fehlende Vorgänge weitergeben soll. Diese drei Aufgaben haben unterschiedliche erwartete Ausgaben.

So prüfst du die tatsächliche Datenform

1. Kleines Beispiel bilden. Verwende in einer Kopie zwei harmlose Geschäfts-IDs: eine mit einem eindeutigen Tabellentreffer und eine ohne Treffer. Trenne nachfolgende Schreibmodule für diesen Test ab.
2. An jedem Übergang zählen. Notiere Eingabezahl, Ergebniszahl und die enthaltenen IDs vor und nach dem Lookup. Untersuche zusätzlich den Fall ohne jeden Treffer. Ein leeres Objekt ist kein Beleg dafür, welcher ursprüngliche Vorgang gemeint war.
3. Ausdruck verfolgen. Welchen früheren Node referenziert .item? Soll genau ein Vorgang oder tatsächlich das erste Element des gesamten Laufs verwendet werden? Eine Ersetzung durch .first() kann die Fehlermeldung beseitigen und trotzdem fachlich falsche Daten auswählen.
4. Zweckgerechte Operation wählen. Geht es nur um vorhanden beziehungsweise nicht vorhanden, prüfe die entsprechenden Data-Table-Operationen in deiner Version. Soll ein Datensatz angereichert werden, führe eine explizite Zuordnung über einen eindeutigen Geschäftsschlüssel durch.
5. Mehrdeutige Schlüssel abfangen. Teste auch zwei Tabellenzeilen mit derselben Referenz. Der Workflow sollte diesen Zustand sichtbar behandeln, statt still einen beliebigen Treffer zu verwenden.

Ein brauchbares Abnahmekriterium

Jede ursprüngliche ID ist danach eindeutig als „gefunden“, „nicht gefunden“ oder „mehrdeutig“ ausgewiesen. Kein Kunde erhält Werte eines anderen Elements. Halte dieses Ergebnis anhand des kleinen Beispiels fest, bevor du die Schreibmodule wieder anschließt.

Häufige Fragen

Erhält „Always Output Data“ automatisch alle Eingaben?

Verlasse dich darauf nicht als Zuordnungsgarantie. Prüfe die konkreten Ausgaben deiner Operation und Version, besonders bei vollständig leerem Ergebnis.

Welche Informationen helfen bei der Diagnose?

Node-Versionen, der fehlschlagende Ausdruck und anonymisierte Eingaben und Ausgaben mit stabilen IDs. Zwei passende Testfälle sind hilfreicher als ein Export voller Kundendaten.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0074 mit KAN KAI WORKS besprechen.