Recover a deleted Airtable field or table

If it just happened, stop and try undo first — Cmd/Ctrl + Z in the same session is by far the cleanest recovery and it restores both the structure and the values. Every other route below is a partial one.

Two different problems. Recovering the values that were in a field and recovering the field’s definition — its type, its select options, its links — are separate jobs with separate time limits. Work out which one you actually need before you start, because the fastest path is different for each.

Compare two schema exports

If it happened in the last few minutes

Undo in the same browser session. Best outcome available. Do it before anyone else edits the base, because undo works against a stack that other people’s changes will push past.
Check the trash. Airtable keeps deleted items recoverable for a window that depends on your plan — deleted tables and records are the usual candidates here. Look before assuming it is gone.
Check revision history on the table or record, again within your plan’s retention window.

If the window has passed

Now you are rebuilding rather than restoring, and the two halves come apart.

Recovering the structure

This is the tractable half, provided you have a schema export from before the deletion. A schema export records the field’s name, type, and options — the exact things nobody remembers accurately a week later. “It was a single select” is easy; the seven option values and their spelling are not, and those are what your filters and automations matched on.

Diff a pre-deletion export against the current one and you get a precise list of what is missing, which you can rebuild field by field. Without an export you are reconstructing from memory and from whatever your automations reference.

Recovering the values

Harder, and often not fully possible. Options in rough order of preference:

A base snapshot. Restores the base to an earlier state — but it restores everything, so any legitimate work done since is rolled back too. If a field was deleted this morning and 200 good records landed after, you are choosing which loss you prefer. Restoring into a duplicate and copying the one field across avoids that trade.
A CSV export you happen to have. Worth checking before anything more elaborate.
Downstream copies. A warehouse sync, a Zapier log, a connected sheet. Often the only surviving copy, and frequently overlooked.

Deleted table vs deleted field

A deleted table is louder and usually easier — it is more likely to be sitting in the trash, and someone notices within minutes. A deleted field is the quieter problem: the base still works, nothing errors, and the absence may not surface until a rollup reads zero or an automation writes to nothing. That delay is what pushes it past the recovery window.

The link-field case deserves its own warning. Deleting a linked record field removes the relationships, and recreating a field with the same name does not bring them back — you get an empty field with the right label. Rebuilding those links means re-matching records, which is only as reliable as the primary field values you match on.

Making the next one recoverable

Every route above depends on having a record of the structure from before the change. That is the whole argument for versioning schema separately from data: a structural snapshot is tiny, contains no record values, and can be kept indefinitely without any of the privacy questions that come with copying your customers’ data.

SchemaWard takes those snapshots on a schedule, keyed by stable Airtable field IDs, and alerts you when a field or table disappears — so the clock starts when the deletion happens rather than when someone notices. It reads schema only; it never fetches record values.

← All Airtable schema guides · SchemaWard home