I built a free n8n workflow that sorts my support inbox for me. Halfway through testing it, the Gmail node quietly erased my data — and the fix taught me something about how n8n actually passes data between nodes.
The problem
If you sell digital products, your support inbox is five different conversations wearing one disguise: refund requests, technical issues, "how do I" questions, license questions, and spam. I was reading and sorting all of them by hand, every day.
So I built Digital Seller Support Triage: a free n8n workflow that watches Gmail, runs each new email through an AI agent, sorts it into one of those five categories, assigns a priority, and logs everything to Google Sheets. For the low-risk categories — usage and license questions — it goes one step further and drafts a reply in Gmail. It never sends anything on its own; the draft just sits there waiting for you to read and approve it.
Like the last kit I built, every node type and parameter was validated against n8n's actual schema with n8n-mcp before any JSON got written. No guessing at node shapes.
The bug I didn't see coming
Static validation passed clean. I ran a real test through n8n Cloud with a sample "usage question" email — the kind that should trigger a draft reply. The AI categorization worked, the draft got created in Gmail successfully. Then I opened my Google Sheets log to check the result.
The row was there, but it was wrong. The category, priority, and summary columns were empty. Instead, two unrelated columns were filled with a Gmail message ID and a raw API response object.
My first instinct was that the column mapping in the Sheets node was misconfigured — an easy assumption, since I'd just changed it from manual to automatic mapping a few steps earlier. That wasn't it.
Here's what was actually happening. The Gmail node that creates the draft doesn't just add data to the item passing through the workflow — when it runs, it replaces $json entirely with its own API response: {id: "...", message: {...}}. Every field my AI triage step had produced — category, priority, summary — was simply gone from that point in the workflow, overwritten by Gmail's own output.
The Sheets node downstream had been written using cross-node references ($('Parse AI Output').item.json.category) specifically to dodge this problem. In theory, referencing an earlier node by name should pull its data regardless of what the immediately preceding node did to $json. In practice, in this version of the Sheets node, those references didn't hold — the node fell back to auto-mapping whatever raw $json it was currently sitting next to, which was Gmail's overwritten data.
The fix: a dedicated normalization step between the Gmail draft node and the Sheets node, one that explicitly pulls from the original trigger and the parsed AI output by name, and hands the Sheets node a clean, predictable object with only the fields it should ever see. Once that step existed, both branches of the workflow — the one that creates a draft and the one that doesn't — converge on the same clean data before logging.
The lesson that's going in the kit's GOTCHAS.md: if any node in your chain overwrites $json (and several common ones do — Gmail, HTTP Request, and others), don't trust a cross-node reference downstream to quietly route around that. Normalize explicitly with a Code or Set node instead.
That's the second real, tested bug in this kit's GOTCHAS.md, alongside a smaller one about a mistyped message-type field in the AI agent's configuration. Both are documented with the actual error messages and the actual fix, not a generic warning.
What's in the free kit
- The validated n8n workflow JSON, already fixed for the bug above
- Five sample support emails, one per category, so you can test the full thing in about two minutes without touching real Gmail data
- A START-HERE file covering setup, including the two things people tend to get stuck on
- GOTCHAS.md with both real bugs and their root causes
Three credentials needed: Gmail, OpenAI, Google Sheets. Grab it on Gumroad: https://ibrh96.gumroad.com/l/zbmpzn
It's also up for review on n8n's own template library — I'll update this once that's live.
What I'm still deciding
Same open question as last time: I'm weighing a paid, niche-specific follow-up kit, and I'd rather build it around real signal than a guess. If you try this one, the comments are open.
Top comments (0)