There's a comforting assumption buried in how most people think about automations: if it fails, it didn't happen. You picture the automation either completing cleanly or erroring out and leaving nothing behind, the way a canceled transaction at a bank leaves your balance untouched.
Airtable automations don't work that way, and the gap between that assumption and the reality is where a specific, expensive class of data corruption lives. A multi-step automation that fails halfway through doesn't roll back the half that already ran. Those changes are committed, permanent, and, worst of all, indistinguishable from the changes a fully successful run would have left. This is the partial commit problem, and it's a close mechanical cousin of the silent-failure patterns that make integrations so hard to trust. And once your automations are writing out to the CRM, the billing system, or any other connected platform, it stops being an Airtable-only problem and becomes a cross-system one.
Within a single database system, a transaction is an all-or-nothing wrapper. You group several operations together, and either every one of them commits or none of them do. The commit is simultaneous: the operations don't take effect one by one as they run, they all land together at the end. So if step three fails, nothing commits at all, and the record is left exactly as it was before the transaction started. There's no half-finished state to undo, because nothing was written until everything succeeded. That's the thing that makes “if it failed, it didn't happen” actually true.
Airtable automations don't come wrapped in that guarantee. An automation is a sequence of actions that run one after another, and each action writes to the database, or out to an external system, independently, the moment it executes. There's no wrapper holding them together and no rollback step waiting in case a later action fails. This isn't a hidden bug, it's just the execution model: actions run in sequence, they commit as they go, and nothing is designed to reach back and undo an earlier one.
There's an important asymmetry here. Within a single system, that all-or-nothing guarantee holds automatically: a failed step means nothing commits, so there's never a half-finished state to clean up. But the moment a step writes to an external platform through the API, that guarantee doesn't extend across the boundary. The external write has already committed on its own, and there is no automatic undo to inherit at all. Worse, that write often can't simply be reversed. Some actions are irreversible by nature: you can't unsend the email a step already fired, and a payment isn't "undone" by a rollback. So the half-finished work just sits there, and deciding what to do about it (reverse it, push it through, or reconcile the other system) is a deliberate design decision, not something a transaction quietly handles for you. This is why a partial commit isn't only an Airtable quirk; it's the default behavior of almost any multi-step automation that touches more than one system and wasn't explicitly designed to handle its own failures.
Picture a four-step automation that fires when a vendor renewal is approved in Airtable. Step one updates the renewal status in the base. Step two pushes the new contract dates to your billing platform. Step three notifies the account owner that the renewal is done. Step four writes the change to an external audit log your finance team relies on.
Now step four fails. Maybe the audit system rejected a required field, maybe its API timed out, maybe a transient network hiccup. It doesn't matter why. What matters is what's now scattered across your systems:
Steps one, two, and three committed. Airtable says the renewal is active, your billing platform has already booked the new contract dates, and the account owner has been emailed that it's done. Step four is where it died, so finance's audit log has no record of any of it. And because Airtable stops an automation the moment a step fails, nothing after step four runs either: there's no cleanup pass, no compensating write, nothing that reaches back to the billing platform to say the rest never happened.
So the renewal now looks finished. Airtable shows it complete, billing shows it booked, the owner has been told. But the audit trail for a contract renewal, the thing you'd reach for in a dispute or a compliance review, silently doesn't exist, and billing is now holding data that lacks any sort of audit trail. Nothing on the Airtable record tells you that: it is visually identical to the hundreds of renewals that ran cleanly. You'll find it months later, when someone goes looking for the audit entry and it isn't there.
The core problem is that a partially-completed record is indistinguishable from a completed one. So the fix is to make the distinction visible and machine-checkable: don't let anything call a record “done” until the entire chain has actually finished.
The cleanest way to do that is a dedicated commit-status field. Instead of individual steps flipping their own “complete” flags as they go, you gate the whole thing:
Lock at the start. The very first action of the automation sets a status field to something like Processing or Staging. This is the automation planting a flag that says a run is in progress on this record, and it is not finished.
Unlock only at the end. The status only moves to Complete as the final action, after every other step, including the ones that write to external systems, has already committed successfully. If the automation dies at step four, that final unlock never runs, so the record stays visibly stuck in Processing. The half-finished state now announces itself instead of hiding.
The shift is subtle but total. Before, the absence of a failure was your only signal of success, and absence is invisible. After, Complete is a positive, deliberate signal that only exists when the full chain ran end to end. A stranded record is no longer camouflaged among the healthy ones. It's wearing a Processing badge it never took off.
For the steps that already wrote to an outside system, that Processing flag is also your starting point for cleanup: it tells you which records did not fully complete the renewal update process, so you can look into the API logs to identify the points of failure and decide what needs reversing.
The commit-status field makes stranded records visible, but visible isn't the same as seen. The final piece is a bit of proactive triage so someone actually notices.
Because a stalled record stays in Processing, you can build a simple filtered view that shows every record stuck in that state past some reasonable time threshold, say, anything still Processing after fifteen minutes when a normal run finishes in seconds. No code, no monitoring service. Just a view that surfaces exactly the records where an automation started and never confirmed it finished. Checked once a day, it turns a silent, invisible failure into a short, boring worklist. That's the whole goal: convert the failures you'd never have found into ones you can't miss.
The lesson underneath all of this: in an environment with sequentially committing transactions, a sequence of steps completing in order is not the same as an operation succeeding as a whole. Every automation that touches more than one table, or more than one system, is quietly making a bet that it'll run all the way to the end. Most of the time it wins that bet. The commit-status pattern is what protects you the rest of the time, when a step fails and leaves a record that looks perfect and isn't.
This is the same discipline that separates a fragile integration from a governed one. It's also where the partial commit problem stops being a single-record annoyance and becomes an architecture problem: when one failed run has already pushed data into several external systems, undoing it cleanly is its own discipline. [“When a failed automation has already written to three outside systems, recovering to a consistent state becomes a cross-system cleanup problem” — cluster futuro: silent failure chains / multi-system commit]
Designing automations that fail safely (that leave every record either genuinely done or visibly unfinished, never deceptively in between) is exactly the kind of architectural rigor InAir builds into an operation. We turn automations that quietly strand records across your systems into ones you can trust to tell you the truth about their own state. Schedule a Discovery Call with InAir to make “done” actually mean done across your workspace.