Automations: The Unattended Chainsaw

As a species, we love power tools. They help us get big jobs done quickly and with less effort. A good chainsaw can slice through a cord of firewood in a blink. A smart operator will take care to wear eye protection, gloves, and even a carbon fibre vest. And because they’re operated by humans, we can easily avoid accidents like mistaking redwood lumber for that new deck as firewood. :wink:

Automations are the equivalent of an unattended chainsaw.

Imagine starting a chain saw and it just takes off at a rapid pace slicing through all the logs while you relax and enjoy a fine beverage. (queue Tim the Toolman growl here).

But now let’s imagine a different scenario - it’s 2 AM and the chainsaw magically starts and begins to slice through all your neighbours’ beautiful redwood privacy fencing? Ooops!

There’s an abundance of posts in this community about automations that don’t seem to run when all indications suggest they should. Of less interest is the opposite - automations that run when you really don’t want them to. Unfortunately, a variety of conditions can cause an automation to unintentionally carry out its mission. And when they do, we tend to point the finger in the direction of our developers or users.

@ScottWorld makes it clear that something as innocent as a user who accidentally deletes a field and then quickly uses the undo feature to restore it – will trigger automations that are dependent perhaps on the deleted field or simply based on the modified status. A mishap like this, of course, sets in motion an unattended chainsaw event that could be catastrophic. And there are many other scenarios that can start an unattended chainsaw incident.

… urged Airtable to further separate “delete field” from “hide field” @ScottWorld

While a good candidate for a UI improvement, adding distance between “delete” and “hide” options will not prevent runaway automation disasters. Users will still do these things and the probability of unintentional clicks because of selection proximity is only a small part of the underlying problem.

Automation disasters are a wooly mammoth in a china shop; it has magnitudes and complexities far greater than any UX/UI changes can effectuate.

The downside of automations is that they fire without deference. Until they can fire with deference, or based on complex rules, there’s not much hope for stemming 100% of this risk.

@Kuovonne is right - there are edge cases where it is near impossible to predict and stop an automation that is about to behave in a harmful way. There is no API that allows us to monitor future automation events in real-time such that we could take evasive counter-actions. As such, it is not just an unattended chainsaw, it is also an unpredictable one.

A runaway automation disaster is the safety equivalent of a chainsaw user in Des Moines being severely injured because someone in Buffalo said Stihl three times and took a shot of Tequila.

Automation users and builders cannot easily connect or understand the dependencies of potential future activity. In the aftermath of an incident, even the experts need time to ponder and assess the true cause of the disaster long after the blood-letting has occurred.

In a #no/low-code world, with power comes responsibility, and this applies to Airtable (mainly) and to developers (mostly).

I implore Airtable to consider some additional safety features for this remarkable and very efficient tool. In the meantime, I’d like to understand two data points from the community:

  1. What measures do you use (if any) to avoid or mitigate the potential damage from unintentional runaway automations?

  2. What are the automation design patterns that lead to problems created by unintentional runaway automations?

Please note that the term “automations” in this article is not limited to Airtable automations; it is possible to create unintentional runaway automations using many aftermarket tools.


To make matters even worse with runaway automations, the undo function doesn’t even work properly in Airtable. If your deleted field was used to filter views, and then you undo the deletion, your view filters are NEVER RESTORED to how they used to be prior to deletion.

So even after your runaway automations have destroyed the integrity of thousands or tens of thousands of records, your base is now left in an unstable state for future records to be improperly processed by automations… if you have automations that are based on those views.

So even though the user is painfully aware that Airtable has already destroyed many of their EXISTING records, the user wouldn’t even know that their base is in a FUTURE unstable state, because as far as they know, they hit the “undo” function, so all of their views should’ve been reverted to normal.

Airtable’s snapshots also don’t work properly, so it is completely impossible to restore to a working copy of the base of how it used to be.

And of course, the biggest problem of all is that simply deleting & restoring a field changes the “last modified time” for every single record in the entire table, so the user CAN’T EVEN PROPERLY EVALUATE WHICH RECORDS WERE DESTROYED by Airtable.

I guarantee you that I am just scratching the surface of the problems here. It would take me 3 pages to outline all of the problems & bugs in Airtable regarding these issues.

I’ve reported over 12 bugs to Airtable in regards to (1) snapshots not working properly, (2) undo not working properly, and (3) runaway automation problems… and my concerns were met with a collective shrug by Airtable.