My n8n Google Sheets Append Wrote Zero Rows, No Error — an Empty Schema Array Was the Cause

A queue-append pattern reused across several workflows had quietly worked for months. Building the next one in the same family, the append executed, reported nothing alarming in the canvas, and the sheet gained exactly zero new rows.

A pattern that had already worked, several times

The append-to-queue pattern is used across a handful of similar content-pipeline workflows: a Code node builds an item with field names that already match a target sheet's column headers exactly, a Google Sheets node appends it, and a webhook or downstream trigger picks the new row up later. This exact shape had been reused successfully building earlier items in the same series, which is precisely why the next build didn't get any extra scrutiny — it was assumed to still work, because nothing about the pattern itself had changed.

The first sign of trouble was an absence, not an error

The webhook fired, the Google Sheets node ran, and the workflow's execution list showed the run finishing without a red X anywhere in the canvas. The only reason the problem surfaced at all was a habit of re-reading the target sheet after any append to confirm the row count actually changed — it hadn't. Trusting the green checkmark alone would have left the queue silently short by one entry, with nothing in the workflow's own UI suggesting anything had gone wrong.

What was actually happening underneath

Opening the failed node's own execution detail (not just the canvas overview) showed the real message: columns.schema is required when mappingMode is defineBelow. The node's columns.mappingMode parameter was set to "defineBelow", a mode meant for explicitly mapping each output field to a specific sheet column one at a time — and its companion columns.schema array, which is supposed to hold that mapping, had been left empty. On an older version of this node, an empty schema under defineBelow apparently still fell through to some default matching behavior. On the current version, it's validated up front and rejected outright before any row is written.

Why `autoMapInputData` was the actual right mode all along

defineBelow only earns its keep when the incoming field names need to be renamed or reordered to match different sheet columns. In this pipeline they never did — the Code node upstream was already naming its output fields to match the sheet's headers one-to-one. For that exact situation, n8n has a second mode, autoMapInputData, that matches incoming fields to sheet columns by name automatically and needs no schema array at all. Switching the node's mapping mode fixed the append immediately, with no other changes required.

The generalizable habit, not just the one-line fix

Two separate lessons came out of this, and only one of them is the actual parameter change. The first: defineBelow with an empty schema is not a safe default to copy forward between workflows on this node type — if field names already match, use autoMapInputData instead, and reserve defineBelow for cases that genuinely need remapping, with a populated schema. The second, more durable habit: a Google Sheets append reporting "success" in the canvas is not proof that a row was actually written. Independently re-reading the sheet after any append — not trusting the execution status alone — is what caught this before it silently dropped a queue item.