Would love if it could be programmed to require approval before processing bulk automations, which often get triggered without meaning to.
For example, I have an automation that is triggered by a view that was filtered based on a single line text field. I changed the field type to that single-select, thereby wiping out the filter in the view, and triggering 493 unwanted automations. Grrrrrrr…
Well, that strikes me as the opposite of automation. A reminder to run a manual process is not unlike an automation process that requires approval, right?
An automation approval process is probably not the ideal feature; rather, an automation that is impervious to failure seems to make more sense. This is where I tell my developers - you haven’t finished the code yet. :winking_face:
And there it is. :winking_face:
You have created an automation process with dependencies that are brittle and prone to unanticipated changes. Any sort of mass process that has a profound impact on messaging, API calls, record deletions, and a host of other things should perform a data integrity check before launching.
More than 50% of the effort required to build a reliable and sustainable automation process is determining the conditions where the process should be allowed to actually execute. Further, much of the effort must be devoted to anticipating the unlikely events like the one you described.
Every risky process should have a checklist to see if all factors have green lights. And when there are red lights, they should trigger exception logs and notifications.
It won’t help after the fact, but in the future, I suggest turning off automations when making schema changes.
The new ability to trigger an automation when a record meets specific conditions instead of when a record enters a view will also help make automations less brittle.
Although, I agree with @Bill.French that developing good automations takes skillful design, I think that writing automations to handle schema changes (beyond renaming tables/fields) gracefully is a bit much to expect.
Never said or intimated such. To be clear - I said this:
[creating] … reliable and sustainable automation process is determining the conditions where the process should be allowed to actually execute
It’s quite easy to create tests and catch issues that may result in calamitous outcomes in the face of a schema change, bad data, modified filter – etc. Accommodating and actually depending on script errors through try/catch are ideal for this.
Yes, an automation for a scripting action could include a lot of error catching. But what about other automation actions? I don’t see how any of the other automation actions, such as creating a record, updating a record, sending an email/message, etc. could possibly handle schema changes, or many other calamitous situations. While, one could use a scripting action for many of those situations, it would be much more difficult for a non-coder, especially for sending a message.
In the meantime, may Airtable could add warnings to a confirmation dialog when a field is deleted or field type changes: “This field is used in X Automations. Changing this field may trigger unexpected runs” or something to that effect.
Now that schema can be altered through scripting, this will only affect changes made in the UI, but its a start. I agree that Automations, by definition, shouldn’t wait for human confirmation.
Many unintended or difficult-to-anticipate “conditions” may occur - most of which cannot be overcome with increasingly complex script. As such, automations should be smart enough to run under the conditions where - and only where - such processes will be successful. And by “successful”, I mean without doing damage or unintended actions.
Any encounters where such conditions are not the case, flag it, log it, notify someone about it. To me, this is a technical requirement not unlike any other technical requirement.
I really appreciate the feedback, even though I only understood a portion of it.
A few things that come to mind:
1- zapier has a feature that does just what i requested
2- i trust an algorithm to register when a unusual number of actions were triggered much more than i trust my ability to design such robust automations.
3- if AT were to build such a feature, they could make it optional.
4- failing this, it would be nice if AT had a master shut-off for all automations. this way anytime i go under the hood i could just easily turn off all the automations without having to think about which ones my actions might affect.
Airtable’s automations are still very new and under development compared to Zapier.
I suggest you provide your feedback to them via the feedback form, just so it won’t get lost in the community.
Unless you have a really large number of automations, it should be fairly easy to turn them off individually from the main Automations screen. I recommend thinking about which automations your actions might affect and how. (It might be only a couple of seconds for some automations, but still some thought.) How else will you know what you can and can’t change?
