Skip to main content

I wanted to share a recent experience in case anyone else has run into the same thing, and if not, to bring it to the community’s attention. It’s one of those odd edge cases that can cause a lot of confusion when troubleshooting automations, and I think it’s worth having on the radar for anyone building complex workflows.

 

Recently, I was troubleshooting an automation that ran in an unexpected way. While reviewing the automation run logs and the record’s historical logs, I couldn’t figure out how it had been triggered. The revision history showed no relevant edits, yet the automation clearly had fired.

 

After digging deeper and testing different scenarios, I eventually discovered the cause, the collaborator had unintentionally undone an action almost immediately after performing it, either by quickly unchecking a box or pressing Cmd+Z (or Ctrl+Z) on their keyboard.

 

Airtable’s automation system is sensitive enough to register the initial change even if it’s quickly reverted. However, Airtable’s record revision history will not log changes that are undone, it only logs updates once they’ve been saved to the record. So in cases like this, no visible edit appears in the revision history, even though the automation still runs.

 

Tip to Diagnose This in the Future:

Add a Last modified by field and a Last modified time field that specifically reference the triggering field. Even if the change is undone too quickly to appear in the revision history, these fields can still give you clues that the triggering field was updated and caused the automation to run.

 

Tips for Preventing Confusion in This Scenario:

There’s no way to stop Airtable’s ability to undo actions with Cmd+Z (or Ctrl+Z), so if you have workflows that trigger from something like a checkbox click, the automation will still run even if the user quickly undoes the action, and there’s no way to “undo” the automation itself.

Some ideas I’ve used:

  • Provide clear updates from the automation so the user can see in the interface that it’s running and when it has finished, even if they undid the triggering action.
  • If your automation kicks off a large workflow, consider triggering it from a button in the record detail page with a popup asking the user to confirm before it runs.

 

Has anyone else run into this? What’s your approach for making this type of workflow as user-friendly as possible?

Hey ​@airvues,

Thanks for sharing! This is actually strange, as my experience is usually the inverse:  automations NOT running if the change is undone too quickly. Would you mind providing additional information of your very specific use case?

There are other use cases where a change will not be shown on the revision history but the automation will still get triggered. Example: If the automation is set to trigger whenever field “Product” gets updated in the Line Items table. If Product field is a linked record field, and the actual linked record does not change, but the primary field of the linked record does change, that will not be shown as a change in the revision history of the Line Item record but will still trigger the automation. 
Furthermore, if the primary field of such linked record field (Product table) is a formula, then you will not even find the change of that specific primary field on the revision history of the Product record. -you could see how this would be tricky if the primary field of Product in turn depends of a linked field called Variant…… and so and so forth. This is were debugging gets really fun :D

I think something similar might happen when triggering automations from updates to lookups/rollups.

Hope this other experience adds some value/kicks off some discussion.

Mike, Consultant @ Automatic Nation

Hi ​@Mike_AutomaticN,

 

Thanks for adding to the discussion. For my specific case, the automation was triggered by a condition where 2 checkboxes would have to be checked in order to trigger. One of the checkboxes you can disregard as it gets checked early in the process, the second checkbox is what the user would push from an interface button. The interface button updates that checkbox to checked and the automation would trigger. It is a long list of actions that happen once triggered. So in this scenario the user clicked the button and then quickly clicked cmd+Z which undid the checked checkbox but the automation continued to run. The user didn't realize they have done this and they didn’t expect the workflow to have run. They never actually told me they have clicked the button at all, so thats how I ended up going on a goose hunt and ran into this. 

 

Since then I’ve made some more user-friendly additions so that they would know what is happening if they were to click the button. Also added a second verification modal (Are you sure you want to do this?) before that button triggers the automation.

 

For the use case you mentioned, yes formula changes dont get tracked on the revision history but they definitely trigger automations as changes. The scenario you shared about the primary field referencing a formula but triggering an automation on another table, that is definitely a fun one. I think using formulas as an automation trigger can be a great use case, specially if you need more sophisticated trigger logic, could save you from having to create multiple duplicates of an automation with different triggers. The downside is the lack of historical data when troubleshooting is needed. Perhaps Airtable should give us a bit more trigger logic options. For example I’ve been wanting a trigger that would trigger on both creation and update, or better date logic conditions. 

 

Reply


Terms & Conditions