Airtable field type changes: what breaks and what is lost
Airtable lets you change a field’s type in two clicks, and it will warn you when a conversion is lossy. What the warning does not tell you is what else depended on that field. This is a conversion-by-conversion reference for the changes that actually cause incidents, ordered with the destructive ones first.
Why these break so quietly
A field type change is a permitted, ordinary operation. Nothing errors at the moment you make it, and the grid still looks right. The damage surfaces somewhere else entirely — a rollup that now reads zero, a filtered view that came back empty, a Zapier step that ran successfully against a field that no longer means what it used to. By the time anyone connects the symptom to the cause, the change is often days old and nobody remembers making it.
One detail worth holding onto: Airtable field IDs are stable across both renames and type changes. The field that broke your automation is the same field it always was, which is why comparing schema exports by ID gives you a clean answer where comparing by name gives you noise.
Conversion reference
Linked record → text Not reversible
What is lost: The relationships themselves. Airtable writes the linked records' primary field values into the cell as plain text and severs the links. The text looks identical, which is what makes this one so easy to wave through.
What breaks: Every rollup, lookup and count field pointing through that link stops resolving. Filtered views that traverse the relationship return empty rather than erroring. Converting the field back to a linked record does not restore the connections — Airtable will try to match records by name, which silently creates new records for anything that does not match exactly.
Attachment → text Not reversible
What is lost: The files. You are left with filenames and/or URLs as text, not the attachments. Airtable's attachment URLs are not permanent, so an exported URL is not a reliable way to get a file back later.
What breaks: Anything rendering the attachment — interfaces, shared views, automations that forward files. Treat this as destructive and take a copy of the files out of Airtable first.
Multiple select → single select Not reversible
What is lost: Every value except one, on any record that had more than one selected. A record tagged with three options keeps one and drops the other two.
What breaks: Reporting built on the multi-value semantics, and any automation whose condition was 'has any of'. The field keeps working, so the breakage shows up as counts that quietly got smaller.
Single select → text Partly reversible
What is lost: The option definitions — the constrained list and its colours. The per-record values survive as free text.
What breaks: The constraint, which was the point of the field. Nothing stops a typo or a new variant being written now, so 'Done', 'done' and 'Done ' become three distinct values. Filters and grouping built on the old options still match the exact string but silently miss everything else. Converting back creates options from whatever strings now exist, typos included.
Number → text Partly reversible
What is lost: Numeric typing and the precision setting. Values remain as strings.
What breaks: Sums, averages and rollups over the field. Comparison filters (greater than, less than) either disappear or start comparing lexicographically, where "10" sorts before "9". Formulas doing arithmetic on the field need an explicit VALUE() conversion or they return errors.
Currency → text Partly reversible
What is lost: The currency symbol, precision and numeric typing. Whether the symbol ends up embedded in the string is worth checking before you commit — it determines whether converting back parses cleanly.
What breaks: Every total and rollup, plus any downstream system expecting a parseable number rather than a formatted string.
Date → text Partly reversible
What is lost: Date typing, timezone handling and the ability to sort chronologically. The value is frozen into whatever string format was displayed.
What breaks: Calendar, timeline and Gantt views built on the field. Relative date filters ('is within the next 7 days') vanish. Date arithmetic in formulas fails. Sorting becomes alphabetical, so 12 January sorts before 3 March.
Checkbox → text Partly reversible
What is lost: Boolean typing. Values become a string form of checked/unchecked, and unchecked rows commonly end up empty rather than a literal "false".
What breaks: Conditions testing the field as a boolean. The subtle one is that an empty string is falsy in most downstream tools but not all — so a filter that used to mean 'unchecked' may now mean 'blank', and those are not the same set once new rows arrive.
A safe order of operations
- Export the schema first, so you have a record of the field’s definition — including select options — as it exists right now.
- Duplicate the base and convert there. Check row counts and spot-check records that had multiple values, blanks, or unusual formatting.
- Search your automations for the field by name before converting. External tools that map by name are the ones that fail silently.
- Convert in production, then export the schema again and diff the two.
Catching it when someone else does it
The order above only helps for changes you make deliberately. Most damaging conversions are made by someone who had no idea four automations depended on the field. SchemaWard snapshots your base structure on a schedule, compares by field ID, and alerts you when a conversion discards data or an option disappears — with a point-in-time record of what the structure looked like before.
Related: why Airtable automations break · recovering a deleted field or table · your Airtable schema, explained