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. :winking_face:
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:
-
What measures do you use (if any) to avoid or mitigate the potential damage from unintentional runaway automations?
-
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.
