n8n Data Table: .item breaks after a lookup?

A workflow receives several business records and looks each one up in an n8n Data Table. A later .item expression fails, or values become associated with the wrong record. Partial matches are particularly troublesome because the number of lookup results may differ from the original number of inputs.

Why a lookup can change the relationship

A report for n8n 2.41.6 describes this combination with Get row(s) and Always Output Data. Q1 n8n documents that .item depends on an unambiguous link to the earlier item; missing or ambiguous relationships can fail. Q2 The Data Table Get operation returns matching table rows, while dedicated operations are available for existence checks. Q3

That does not establish a general product defect. First decide whether the workflow should enrich each input, select records already present, or pass through records that are absent. Those tasks have different expected outputs.

Inspect the real data shape

1. Build a small example. In a workflow copy, use two harmless business IDs: one with a unique table match and one without a match. Disconnect downstream writing nodes for this investigation.
2. Count at each boundary. Record input count, output count and the IDs present before and after the lookup. Also examine the no-matches-at-all case. An empty object does not establish which original record it represents.
3. Trace the expression. Which earlier node does .item reference? Should it select the corresponding record, or genuinely the first record in the entire run? Replacing it with .first() can remove the error while selecting the wrong business data.
4. Choose an operation that matches the task. For a simple present-or-absent decision, examine the corresponding Data Table operations in your installed version. For enrichment, join the result explicitly using a unique business key.
5. Handle ambiguous matches. Include a test with two table rows sharing the same reference. The workflow should expose that condition rather than silently selecting an arbitrary match.

A meaningful acceptance check

Every original ID should be accounted for as found, absent or ambiguous. No customer record should receive another customer's values. Keep the small example and its expected results as evidence before reconnecting writing nodes. If an output lacks the business key required for this check, fix that visibility gap first.

Frequently asked questions

Does Always Output Data automatically preserve every input?

Do not treat it as a guarantee of item correspondence. Inspect the outputs produced by your specific operation and version, especially when the result is completely empty.

What should I provide for diagnosis?

Provide node versions, the failing expression and anonymised input and output examples retaining stable IDs. Two carefully chosen test records are more useful than an export containing customer data.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0074 with KAN KAI WORKS.