← All notes

You renamed a column. The automation stopped seeing it.

4 min read

Somebody widened the columns, fixed a typo in a header, and changed "Phone" to "Phone number" because the sheet was going to be shared with a new supplier. It took eleven seconds. Nobody wrote it down, because nobody had done anything.

Zapier's help page says what happens next: "When you rename a column, Zapier loses track of where the data for that column is located. As a result, the field for that column disappears from the Zap editor."

That is the whole mechanism. The platform did not memorise your spreadsheet. It memorised where a piece of data sat and what it was called, and both of those were part of the agreement.

Why the tool cannot just cope

It is tempting to see this as a missing feature. It is closer to a boundary.

An automation platform is not maintaining a live model of your business. Zapier is explicit that it is not a synchroniser at all: "Zapier does not support two-way syncing between apps. Zap workflows are one-way automations." A one-way automation takes what it was pointed at and moves it. Point it somewhere else, even by a rename, and there is nothing to notice the substitution — only a field that is no longer there.

The people most surprised by this are the ones who built the workflow themselves, which is most owners of small businesses. Building it felt like configuration. Breaking it feels like nothing at all.

What it looks like from the outside

Rarely a red banner. Usually one of these.

Records arriving with a hole in them. Everything still runs; the field that lost its home comes through empty. Orders with no phone number, invoices with no reference, contacts with no company. The workflow is not failing — it is succeeding with less.

A step that quietly does not match. Anything that looks up a row by a column now looks up nothing, so instead of updating the customer it creates a second one. That is a fast route to one customer existing twice in systems you cannot easily reconcile afterwards.

A workflow you cannot switch back on. You open the editor to change something unrelated, and it will not publish because a mapping points at a field that no longer exists.

The gap between the rename and the symptom is what makes this expensive. A week of half-filled records is a week of manual repair, and by then nobody connects it to the spreadsheet tidy-up on Tuesday.

Making your own edits safe

The trick is to treat structure and content as different activities. Adding rows is content. Touching headers is a change to an interface something else depends on.

Turn the workflow off before you touch the header, and on afterwards. This is what the vendor recommends, and it converts a silent breakage into a planned two-minute gap. After the rename, retest the step so it can find the columns again, remap what needs remapping, and save.

Freeze the header row by agreement. In practice: display names in a presentation copy, machine names in the sheet that automation reads. If a supplier needs prettier labels, they get a view, not the source.

Give the machine-read sheet a visible warning. A first row that says this sheet is read by an automation, with the name of the workflow and who to ask, in red. Not elegant, entirely effective, and it survives staff changes better than any convention.

Know which sheets are load-bearing. Most businesses have two or three spreadsheets that quietly run operations and a folder of harmless ones. If you cannot name yours, that is what a register of what is automated is for.

Check the output after any structural edit. One record, end to end, with eyes on it. Not the test button — a real record, viewed where it lands.

The wider point about tools you can change yourself

The appeal of building it yourself is that changes are cheap. That stays true, but only for the changes the tool understands as changes.

Renaming a header, moving a folder, reordering options in a form, changing a status label from "Paid" to "Paid ✓" — these all feel like housekeeping and all of them are edits to something a workflow depends on. The category is not "risky changes", it is "changes to things that are named". That distinction is part of what makes no-code convenient right up until it is not.

If you want the map rather than the rule

The generic advice — do not rename things carelessly — is easy to agree with and hard to act on, because nobody knows which names are load-bearing.

The useful version is specific to you: this sheet, these three columns, that form field, this folder path. Producing that list, and what breaks when each one moves, is part of a process audit: $299, three business days.

Related: how to keep track of every automation your business runs — the register is what turns "which sheets are load-bearing" from a memory test into a lookup.