Hi guys,
I’m running into an issue with the Google Sheets node (n8n-nodes-base.googleSheets, typeVersion 4.5), where rows are appended via the appendOrUpdate operations are being written outside the boundary of a native Google Sheets Table, rather than into the next available row within the Table.
The target sheet uses the native Google Sheets Tables feature (Insert → Table). The Table spans approximately A1:N7, with row 1 as the header row and rows 2–7 containing typed-column placeholders (date, currency, person chip). The Table is named “Invoices”.
Expected vs. actual behavior
When a new row is sent to the node, it should be inserted within the Table boundary, either by filling the next empty Table row or by extending the Table to accommodate the new record, so that the row inherits the Table’s column types, formatting, and structured references. Instead, the row is written to the first empty row immediately below the Table’s current data range, outside the Table boundary; it does not become part of the Table and does not inherit its column types or formatting. This happens regardless of whether the Table contains empty placeholder rows or only populated rows.
I’ve attached a screenshot of the destination sheet showing the issue, and I’m happy to share a sanitized export of the workflow if that would help. Thanks for taking a look.
1 Like
Yeah this looks like n8n is treating the sheet like a normal range, not like Google’s newer native Tables feature.
I’d test with a blank row already inside the table and also try setting the range to the table area.
If it still appends below the table, I’d treat it like a Sheets node limitation/bug and either use a normal range workaround or hit the Sheets API directly.
1 Like
Welcome @ernest28 to our community! I’m Jay and I am a n8n verified creator.
This is a known gap - n8n’s Google Sheets node calls the Sheets API v4 at the spreadsheets.values level, which has no awareness of Google Sheets native Tables. The Tables feature sits on top of regular sheet ranges but the API doesn’t expose it the same way, so appending a row just finds the next empty row in the range without “inserting” a row into the Table object. The only real workaround right now is to avoid using native Tables as the target - use a regular range instead and apply formatting manually, or use the Sheets API node with a direct batchUpdate call if you need the row to register inside the Table structure.
1 Like
@ernest28 confirming what @OMGItsDerek + @nguyenthieutoan said — the Sheets API values.append endpoint that n8n calls has no concept of native Tables, so the row lands outside the boundary by design. the workaround when u still want Table-aware inserts is calling spreadsheets.batchUpdate directly via HTTP Request with an insertRange request that explicitly extends the Table.
heres the HTTP Request node JSON for the workaround:
insertRange shifts existing cells down + extends the Table object, then updateCells writes ur row into the freshly-created row INSIDE the boundary. column types + formatting get inherited from the Table definition. adjust startRowIndex/endRowIndex to wherever the Table currently ends (or query it first with spreadsheets.get + includeGridData=false to find the live boundary).
1 Like
