The trigger that looks retroactive but isn't
Airtable's Automations feature includes a trigger called "When record matches conditions." On paper it sounds like a standing filter: define the conditions, and any record that satisfies them should fire the automation. In practice it behaves very differently, and that gap is the source of one of the most common "why didn't this run" tickets teams run into after setting up Airtable automations.
The trigger only fires on a transition -- the specific moment a record changes from not matching the conditions to matching them. It does not evaluate the records already sitting in your base when you create or turn on the automation, no matter how well they satisfy the filter. Airtable isn't scanning your table on a loop and reacting to current state; it's listening for edits and checking whether that particular edit just caused a record to cross from "doesn't match" to "matches."
Where this actually bites teams
The pattern shows up constantly because of how bases get built in practice. A team populates a Projects or Requests table with real data first -- much of it already sitting at a status like Status = "Approved" -- and only afterward adds an automation meant to post a Slack message or create a linked record whenever something is approved.
They test it by opening an already-approved record and resaving an unrelated field, or by scrolling through the table expecting the backlog to fire retroactively. Nothing happens, because none of those records just transitioned into matching -- they were already there before the automation existed. The team concludes the automation is broken, when it's actually working exactly as designed; it simply has no history to react to.
The toggle-off, toggle-on trap
A second version of the same problem happens when a team pauses an automation -- to edit it, to debug something else, or just while reorganizing a base -- and then turns it back on. Any record that matched the conditions and then un-matched and re-matched while the automation was off is invisible to it. Airtable only evaluates transitions that happen while the trigger is live and watching; it keeps no queue of conditions-met events from while it was paused.
Why "When record is updated" doesn't fix it either
A common first fix is to swap the trigger to "When record is updated," assuming that at least catches edits to existing records. It does fire on more events, but it still only fires going forward from the moment the automation is active -- it has the same blind spot for records that already exist untouched in the base. It also fires on any field edit to a matching record, not just the condition field, so without a filter step immediately after the trigger it tends to run far more often than intended, which creates its own cleanup problem on a base with heavy editing traffic.
What actually clears the backlog
There's no native "run this against everything that already matches" button, so the fix has to manufacture a transition on purpose:
- Force a re-save. Add a throwaway checkbox or formula field, then bulk-edit the status field on the backlog records to something else and back to the matching value. That edit is a real transition the trigger will catch, even though the underlying data hasn't meaningfully changed.
- Run a one-time script. Airtable's scripting extension can iterate every record in a view and rewrite the condition field in place, which produces the same transition for an entire backlog in one pass instead of a manual bulk edit.
- Build the automation before the data, where you can. On a brand-new base or table, turning the automation on before records start flowing in avoids the backlog problem entirely, since every record that reaches the matching state does so as a genuine transition.
Either backlog fix is a one-time cost -- once the automation is live and catching transitions as they happen, it behaves exactly the way teams expect going forward. The trap is assuming it already covers the data that existed before you flipped it on.
For the full range of trigger types Airtable's automations support, see the integrations and automation overview, or start from the Airtable application overview for the broader feature set. More breakdowns like this one are in the implementation guides.