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.