fixmation.Get my quote
Integrations18 min readPublished September 2026

Somebody tidied the spreadsheet, and the automation kept running

Zapier keys on the row number, Make asks you to type one in, and n8n matches on a value in a column. So sorting a sheet, deleting rows or hiding a column breaks a different thing on each platform, and the failure is usually silence rather than an error. Here is what each one tracks.

The edit that breaks nothing visible

A spreadsheet is the most common database a small business has, and the only one that anybody in the office is allowed to open and tidy. Somebody sorts it by date. Somebody deletes the test rows from March. Somebody hides two columns because they were in the way.

Nothing announces itself. The automation keeps running on its schedule, the runs stay green, and it starts reading the wrong row, or writing over the headers, or processing nothing at all while reporting success.

The reason it varies so much between platforms is that the three of them track different things. One keys on where a row sits, one asks you to say where it sits, and one looks for a value. Knowing which one you are on tells you which edits are dangerous.

What does Zapier actually track?

The row number. Zapier says so in plain words, and then spells out the arithmetic of the failure:

Google Sheet triggers use a deduplication process to identify new rows. This ensures that your Zap only acts on data it has not processed before.

To deduplicate in Google Sheets, Zap workflows use the row number. For example, if you create a new row, making it row 100, the Zap will detect it and trigger. If you then add another new row (row 101), the Zap will only trigger for row 101, as row 100 has already been processed.

If you then delete five existing rows from your sheet, the remaining rows get renumbered. Zapier's deduplication system is still expecting new rows to appear from row 101, and will not trigger when the next 5 rows (96-100) get filled in.

Read the last paragraph slowly, because it describes a silence rather than an error. Five rows are deleted, five later rows arrive, and the Zap does nothing at all for them. In Zapier's own words on that page, there is no corresponding Zap run in your Zap history, and nothing sends an alert about a run that never started.

The dangerous failures here are the quiet ones. A Zap that errors sends you a notification. A Zap whose deduplication counter has drifted past your data just sits there, switched on, doing nothing.

Which edits does Zapier say will break a Zap?

Six, and they are the six things people do to a spreadsheet:

EditWhat Zapier says happens
Delete rows or columns"This can cause Zapier to lose track of which rows it has already processed. As a result, the Zap may miss data."
Add rows anywhere but the bottom"New rows only trigger when added to the bottom of the sheet. Any row added into the middle of the sheet would not be considered a new row. Additionally, adding rows into the middle pushes existing bottom rows into a new position and causes the Zap to trigger again for data it has already processed"
Sort the worksheet"Sorting your worksheet changes the order of the data. As a result, it interferes with Zapier's ability to identify which rows it should trigger on."
Rename, add or rearrange columns"the data in your sheet will not match the Zap's expected structure."
Rename the spreadsheet or worksheet"the Zap will no longer be able to locate it when it connects to Google Sheets."
Freeze, hide or protect rows or columns"this may affect how Zapier can access the information from your sheet."

All six quotes: Google Sheets error: Zap not triggering, Zapier Help Center.

Zapier's own remedy is a procedure rather than a setting, and it names the part everyone skips:

If you update your spreadsheet while your Zap is turned on, your Zap may error or you may see unexpected behaviors. [...] You must repeat this process every time you or a teammate updates the spreadsheet.

"Every time you or a teammate" is the sentence to send to whoever else has edit access. Turning the Zap off before editing works. Remembering to do it, forever, across everybody with the link, is the part that fails.

Two more Zapier rules worth having, from the same page: headers are read from row one only, and blank rows matter.

Headers are only recognized in the first row. Zapier will not recognize headers in any other row of your worksheet.

Avoid blank rows between rows that contain values. If you're trying to use a Zap to add new rows to your spreadsheet, it will always add rows after the last row with values. Similarly, rows with formulas, but no visible values are not considered empty.

That last clause catches people who filled a column with a formula down to row 5000: to Zapier those rows are not empty, and new data goes after them.

Why does an updated-row Zap stop firing on a status column?

Because the updated-row trigger tracks something different again: whether the value in that column is new to that row.

When you update a column in an existing row, Zapier only detects new values introduced to that column. If you change the value back to one that Zapier has previously seen in that row, it won't trigger the Zap again.

This is the trap on every status column that cycles. An order that goes to Shipped, back to Pending and to Shipped again fires once. Zapier's own suggested fix is to trigger on a column whose value is always new, such as a timestamp, rather than on the status itself.

What does Make track?

For updates, a row number that you type into the module:

Row number - Enter the number of the row you want to update.

Which means the identity of the row lives wherever you got that number from, usually a search step earlier in the scenario. Nothing keeps it fresh by itself, so a scenario that stores a row number anywhere and reuses it later is storing a value that a human can invalidate with one sort.

Two documented behaviours decide whether your triggers see anything at all:

Watch New Rows - Triggers when a new row is added. If a sheet contains a blank row, Make doesn't process all subsequent rows.

Watch Changes - Triggers when a cell is updated. The module only watches for changes made in the Google Sheets app by the user. Script executions and API requests do not trigger this module. The module does not watch for newly added rows to the sheet.

The first one is a single blank row stopping everything below it. The second is the one that surprises people building multi-step systems: if another automation writes into the sheet through the API, Watch Changes does not see it. Two of your own tools can share a sheet and never notice each other's writes.

Make's column identity is a choice you have already made

Make is the only one of the three that hands you the tradeoff explicitly, in a setting most people click past:

Use column headers as IDs of the columns - If Table contains headers is enabled, select whether to use column headers as IDs of the columns. If set to Yes, column header names are used as stable IDs. As long as you don't rename your columns in the sheet, existing mappings will continue to work even if other columns are added, removed, or reordered in the table. If set to No, column position will be used as the ID. The module will continue working when columns are renamed, but not if other columns are added, removed, or reordered in the table.

That is the cleanest statement of the whole problem published by any of the three vendors. You are choosing which human edit is survivable. Headers as IDs means renaming a column breaks you. Column position means inserting a column breaks you. There is no option that survives both, and the sheet does not know which one you picked.

What does n8n track?

A value in a column, which is structurally the safest of the three:

Append or Update Row: Use this operation to update an existing row or add a new row at the end of the data if a matching entry isn't found in a sheet.

Update Row: Use this operation to update existing row in a sheet. This operation only updates existing rows.

Matching on a value means a sort does not touch you: the customer reference is in the same row it was in, wherever that row has moved to. The price n8n pays is at the other end, in how it decides where the data is:

By default, n8n appends empty rows or columns and then adds the new data. This approach can ensure data alignment but may be less efficient. [...] But if the existing sheet data has inconsistencies such as gaps or breaks between rows and columns, n8n may add the new data in the wrong place, leading to misalignment issues.

And one more default that quietly decides which row wins:

If your filter matches multiple rows, n8n returns the first result.

Duplicate reference numbers in a sheet are common. The first match is not necessarily the right one, and nothing tells you there were others unless you change the setting that returns them all.

Three platforms, three different dangerous edits

What identifies a rowWhat identifies a columnThe edit that hurts most
ZapierThe row number, tracked internally for deduplicationHeader names, read from row one onlyDeleting rows, or sorting
MakeA row number you supply to the moduleYour choice: header names or column positionThe one your setting does not survive: renaming, or inserting
n8nA value in a column you nominate, set as Column to Match OnRow one by convention, with the data range auto-detected unless you pin itGaps and blank rows that shift the detected range

Every cell in that table comes from the vendor pages quoted above, except n8n's shifting read range, which comes from the moderator's answer below.

What this looks like when it happens to somebody

The reports read like haunted houses, because from inside the sheet nothing is wrong. A Zapier user in late August:

My Google Sheets trigger reads the wrong row of data when a new form is submitted. It does increase by 1 row for each form entry, but it's reading rows that are 100 past the current entry, and returning empty data.

He worked out the likely cause himself a day later, and it is worth reading as a suspicion rather than a diagnosis, because nobody from Zapier answered the thread:

a few days ago when I sent in my question, the row ID was 152, and now it's less. I suspect that someone deleted the other test rows that I had.

  • the same user, same thread, Zapier Community, 31 August 2026

On Make, a scenario that had been running fine started inserting rows above the header row. Asked whether anything had changed in the sheet, the owner's answer was the most ordinary sentence imaginable:

Honeslty the only changes I made was I hid some columns because they were annoying and useless for the purpose I needed the entire scenario

Nobody from Make answered it. A community champion guessed the hidden columns had stopped the module finding the header row, and the thread closed when she pasted the headers back and it worked, so treat it as a correlation. What it illustrates is the shape of the problem: the edit felt like housekeeping, not like touching a database.

The n8n case has an answer, and it comes from a community moderator:

n8n's append writes empty rows or columns before adding the new data, so a scraper appending into the same sheet for months can leave a gap that shifts where the read starts. Pin the range on the node so it stops resolving on its own: on Get Existing Jobs open Options > Add Option > Data Location on Sheet, set Header Row to 1 and First Data Row to 2, then re-run.

That matches what the documentation says about append leaving gaps, with the moderator adding the step the docs do not take: from data written in the wrong place to the read range itself moving.

The ceilings nobody plans for

Two of Google's own limits matter once a sheet is genuinely load-bearing:

Up to 10 million cells or 18,278 columns (column ZZZ) for spreadsheets that are created in or converted to Google Sheets.

And the API quota, which is what an automation actually consumes:

Sheets API has per-minute quotas, and they're refilled every minute. For example, there's a read request limit of 300 per minute per project.

The table on that page puts reads and writes at 300 per minute per project and 60 per minute per user per project. A batch job that loops row by row rather than reading a range hits the per-user figure quickly, and the response is a 429 that your platform reports as a failed step.

The same page carries a line worth a diary note:

Exceeding the quota request limits is planned to incur charges to your Google Cloud billing account later in 2026.

How to build a sheet that survives being used by humans

  1. Give every row an identifier that is not its position. An order number, a customer reference, a generated id in column A. None of the three vendors documents this as a recommendation, so treat it as our advice rather than theirs, but it is what makes the rest of this list possible.
  2. Look the row up by that identifier at run time, instead of storing a row number. Zapier documents this route: its lookup action returns a row id that, in Zapier's words, "will dynamically update each time the Zap runs", and its guidance for working across sheets is to use "a unique identifier, like an email address or customer reference number, that exists in both sheets".
  3. On n8n, match on a column and pin the range. Column to Match On for the write, and Data Location on Sheet with an explicit header row and first data row so automatic detection cannot drift.
  4. On Make, decide the column identity setting deliberately and write the decision down next to the scenario. Headers as IDs means nobody may rename a column. Column position means nobody may insert one.
  5. On Zapier, trigger on a column whose value is always new if you need updates to fire, and keep the header row in row one with no blank rows above your data.
  6. Protect the sheet from casual tidying. Google's protected ranges, a locked header row, and a plainly named tab that says it is machine-read. The fix for "somebody sorted it" is mostly social, and a warning in row one costs nothing.
  7. Read ranges, not rows, when processing in bulk, so a job that touches a thousand records does not spend a thousand requests against a per-minute quota.
  8. Watch the runs, not the sheet. All of these failures look like success from the outside, which is why nothing tells you until a customer does.

When to stop using a spreadsheet for this

There is a point where the sheet is a database with a spreadsheet interface, and the interface is the problem. The signals are concrete: more than one automation writing to the same tab, anybody outside the automation's owner editing it regularly, row counts in the tens of thousands, or a second system that now needs the same records.

Zapier's own article suggests moving to its Tables product for exactly this reason, and that is a vendor suggesting its own tool. The neutral version: an actual database, or one of the spreadsheet-shaped databases, removes the class of failure this article describes, because a row's identity stops depending on where it sits.

When this is a job to hand over

Adding an id column and switching one action to look up by it is an afternoon, and if you can see which step is wrong, do it yourself.

It becomes a job when the sheet has been writing to wrong rows for weeks and somebody has to work out which records are wrong, when two automations share a tab and neither owner knows what the other writes, or when the answer to "which column identifies a row" is that none does. That is finite work with a price attached before it starts, which is what Fix S and Fix M cover, and rebuilding a sheet-backed workflow is a common shape of the Zapier work we take.

A related failure worth ruling out at the same time: if the automation has been running twice on the same record rather than writing to the wrong one, that has a different cause and a different fix.

Sources

  • Google Sheets error: Zap not triggering - Zapier Help Center, updated 29 May 2026, read 6 September 2026. Deduplication by row number, the arithmetic of a missed trigger after deletions, and the six spreadsheet edits that break a Zap.
  • Work with Google Sheets in Zap workflows - Zapier Help Center, updated 29 May 2026, read 6 September 2026. Headers recognised only in the first row, blank and formula-only rows, and the requirement to repeat the turn-off and re-test process on every edit.
  • Google Sheets: Updated Spreadsheet Row trigger isn't working - Zapier Help Center, read 6 September 2026. The updated-row trigger detecting only values new to that row, and the timestamp column as the documented workaround.
  • Find and update spreadsheet rows in Google Sheets on Zapier - Zapier Help Center, updated 31 March 2026, read 6 September 2026. Lookup column and lookup value, the dynamically updated row id, and the unique identifier shared between sheets.
  • Google Sheets modules - Make apps documentation, read 6 September 2026. The Row number field, Watch New Rows stopping at a blank row, Watch Changes ignoring API writes and new rows, and the column-headers-as-IDs tradeoff.
  • Google Sheets node - n8n Docs, read 6 September 2026. Append or Update Row, matching on a column, appended empty rows causing misalignment, automatic range detection, and the first-match rule on filters.
  • Google Sheets node reading "empty" in all rows even when the sheet has data? - n8n Community, 24 August 2026, read 6 September 2026. A sheet that stopped reading correctly with no change to the node, and the moderator's instruction to pin the data location.
  • Google Sheets is reading the wrong row data - Zapier Community, 30-31 August 2026, read 6 September 2026. A trigger reading a hundred rows past the data, and the reporter's own suspicion that somebody deleted test rows. No Zapier employee replied; the responders carry partner badges.
  • Google Sheets Adding Row Error: data inserted above headers - Make Community, 24 August 2026, read 6 September 2026. Rows inserted above the header row after the owner hid some columns. Answered by community members and not by Make, and quoted here as a correlation rather than a diagnosis.
  • Files you can store in Google Drive - Google Drive Help, read 6 September 2026. The ten million cell and 18,278 column limits.
  • Usage limits - Google Sheets API documentation, read 6 September 2026. Per-minute read and write quotas per project and per user, and the note that exceeding them is planned to incur charges later in 2026.

Integration dropping data between systems? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.