SI Back Office

Platform · updated 2026-10-11

Airtable bases: automations that fail or skip records, and tables that repeat themselves

Documented causes of failed and skipped automation runs, limits that count failed runs, and how linked records match, with the outcomes that fit each.

Two kinds of trouble in an Airtable base

Airtable problems tend to fall into two groups. The first is an automation that fails, or does not run for some records. The second is a table whose structure has outgrown its purpose, typically one that repeats a customer or supplier on every row. They need different jobs, although the second often exposes the first, because automations and lookups that depend on the old columns break when the structure changes.

Why automations fail or skip records

Airtable's troubleshooting article shows that triggers fire on a change, not on a state: records already matching when an automation is switched on do not trigger it. Action inputs that resolve to nothing, for example an empty linked record in a recipient field, fail the run. Scripts have a 30-second network timeout. Runs are metered per workspace each month and failed runs count, and a switched-off automation still takes a slot against the base's cap. The person who last turned an automation on receives the failure email, or the workspace owners if they have left.

Why restructuring needs care

Airtable matches text to linked records by the linked table's primary field, exactly, so spelling variants create extra records. Commas split values into several links, a formula primary field blocks record creation, and deleting a linked field leaves the other side as text and breaks lookups and automations that used it. The safe route is a duplicate base, an approved key list, reconciled counts, and the old columns kept until every dependency is repaired.

Choose the outcome that matches the symptom

One automation fails or skips records: the outcome for one automation repairs it on a duplicate base and proves three cases and a failing one with an alert. One repetitive table needs splitting: the outcome for one table into a parent and a child, with a reconciliation sheet. Nobody is told when automations fail: the failure-alerts outcome. Work happens on a duplicate base, you decide when your team moves onto the duplicate, with a cut-over note and a check for records added or deleted since the snapshot, and we ask for no record exports, passwords or invitations in a first enquiry.

Sources and limits