Why Airtable automations break — and how to see it coming
Most broken Airtable automations are not logic bugs. The scenario was correct when it was built, and then the base changed underneath it. The automation keeps running against a structure that no longer matches what it expects.
The four changes that cause it
A field changed type
Single-select to text is the classic. The automation still finds a field with the right name, so nothing errors — it just starts writing values that no longer match any option, and every filter built on that field quietly stops matching.
A field was renamed
Airtable's own automations follow the field by ID and survive this. External tools that matched by name — plenty of Zapier and Make setups do — do not. The step keeps running and writes to nothing.
A select option disappeared
Remove an option from a single-select and any automation writing that value now fails or silently no-ops, depending on the tool. Filtered views built on the option simply return empty, which reads as 'no work to do' rather than 'something is broken'.
A field or table was deleted
The loudest failure, and still often slow to notice — a scheduled scenario that only runs weekly may not surface the error for days.
Why these are hard to catch
Every one of them is a valid, permitted operation inside Airtable. Nobody did anything wrong, no error is raised at the moment of the change, and the base looks fine. The failure shows up somewhere else — in Zapier’s task history, in a report that came back empty, in a customer email that never sent — and by then the change is often days old and untraceable.
This gets worse the more people touch the base. A teammate tidying field names, an installed app adjusting a type, a template update — all routine, all capable of breaking an integration nobody remembered was mapped to that field.
How to find the change that broke it
- Start from the field, not the automation. Identify which field the failing step reads or writes, then check whether its type, name, or options changed recently.
- Compare structure, not data. A schema export from before and after gives you a diff. That is usually faster than reading revision history, which is per-cell and buried in noise.
- Prefer IDs over names. Where a tool lets you map by field ID, do it — renames stop being breaking changes.
Catching it before the automation does
The fix for a class of problem that surfaces late is to shorten the gap. SchemaWard snapshots your base structure on a schedule, diffs each snapshot against the last, and alerts you when a change is the breaking kind — a type conversion that discards data, a deleted field, a removed select option — rather than every time someone edits a description.
How this differs by tool
The failure mode depends on how your tool references fields. That single detail decides whether a rename is harmless or catastrophic.
Zapier
Zapier resolves Airtable fields when you build the Zap and stores that mapping in the step. A renamed field commonly leaves the mapping pointing at something Zapier can no longer resolve, so the step either errors or writes nothing — and because many Zaps are triggered rather than scheduled, the failure sits in Task History until someone looks. Turn on Zapier’s error notifications if you have not; it converts a silent failure into an email. Re-open and re-map the affected step after any field rename.
Make
Make maps fields inside each module’s configuration. The type-change case is the nasty one here: the mapping still resolves, so the scenario reports success while writing values that no longer match any valid option. Check the scenario’s execution history for runs that “succeeded” but produced no downstream effect — that pattern is almost always a schema change rather than a logic bug.
n8n
n8n workflows frequently address Airtable columns by name in expressions and code nodes, which makes them the most rename-sensitive of the three — an expression referencing a column that no longer exists yields undefined rather than an error, and that undefined propagates quietly through the rest of the workflow. Grep your workflow JSON for the old field name after any rename; it is faster than clicking through nodes.
Whichever tool you use, the durable fix is the same: know the field changed before the automation runs again. See what each field type conversion actually discards.