n8n Automation Hub
A workflow that reads one row and fans out to seven platforms
This publisher runs once a day, picks the first row marked "pending" from a Google Sheet of portfolio projects, has an LLM write platform-specific posts, then publishes to LinkedIn, X, Threads, Contra, Telegram, Facebook, and Instagram before marking the row done. A long, branching chain by necessity — one project, seven different publish paths, several of which (LinkedIn's image upload, Instagram's story vs. feed post) need multiple nodes of their own.
Where "undefined" showed up
Checking a flagged run, the title and body text were `undefined` in the Telegram summary, the Contra post, the X post, and five more nodes besides — different platforms, same missing value. Every one of those nodes referenced the data it needed with n8n's `$('Some Earlier Node').item` syntax: reach back to a specific named node anywhere in the workflow and grab the item currently being processed.
Why the shortcut stops working
`.item` isn't a direct lookup — it resolves through n8n's pairedItem lineage, the chain of "this output item came from that input item" links each node leaves behind as data flows through. That chain has a practical depth limit. Every one of the nine broken references sat five to eight nodes downstream of the node they were pointing at — Register LinkedIn Upload, Download Image, Upload Image to LinkedIn, Post to LinkedIn, Log to PublishLog, Update Project Status, and the seven publish nodes all reaching back to nodes that far upstream. Close, it resolves fine. Far enough, and `.item` returns `undefined` with no error thrown — just silently wrong.
The fix, and why it's safe here
Replaced every `.item` reference in the workflow with `.first()` — get the first item from that node's output, full stop, no lineage tracing involved. That's only a safe substitute when a node genuinely emits one item per run, which this workflow does: it never batches, never splits, one project per execution. A workflow that fans out to multiple items per run would need a different fix, because `.first()` would then silently grab the wrong item just as confidently as `.item` grabbed nothing.
The second bug hiding behind the same symptom
Once the undefined values cleared, a real content bug was still there underneath: the Facebook and Instagram posts were never broken by the reference bug at all — they were built from `post_title + linkedin_text` reused verbatim, because nobody had ever given those two platforms their own generated copy. Fixed by adding dedicated Facebook and Instagram fields to the LLM's output schema and pointing those two nodes at their own text instead of borrowing LinkedIn's.
What to check if this pattern looks familiar
Any n8n workflow with a `.item` reference reaching back more than two or three nodes is a candidate for this exact failure, and it won't announce itself — the execution log shows green, the value is just quietly wrong. `.first()` (single-item workflows) or `.first()`/explicit indexing tied to the actual upstream node reference (multi-item workflows) are both safer than trusting pairedItem tracing across a long chain.