I am excited to share with all of you that as of today conditional automations are now available in Airtable for all users.
Conditional logic lets you trigger groups of automation actions only when certain conditions have been met, ensuring your automations are primed to do exactly what you want. Once you’ve set up conditional logic, Airtable will check the first conditional group you’ve set—if the conditions for a group have been met, the actions in that group will run.
A few common questions:
Do conditional actions count towards the total number of 25 actions allowed per automation?
Yes, conditional actions do count toward the total number of actions allowed for each automation.
Can I nest conditions in automations?
We do not currently allow for nesting conditional groups in automations at this time.
Try it out for yourself in your base here and let us know how you’re planning on using this new feature below! :tada:
As I understand, Airtable is only able to check the conditions in order. If one of the conditions is satisfied, it stops looking to the other conditions.
Is there any way to check for all conditions, and take different actions for each satisfied condition?
Welcome to the Airtable community!
I am seeing the same behavior as you–once a condition is met, only its actions are run, and no other actions can be run.
Thanks for flagging to the team @Jordan_Scott1 - I’d also like to add my vote to being able to move existing actions into the Conditional Actions area - it’s a real pain having to re-create them, or accidentally creating them in the wrong area. Drag and drop is king here!
Same here, which is proving maddening given the difficulty of recreating action groups from scratch each time. I would have saved most of a day of wasted time had this been more clear in the documentation.
I’d hoped conditions might help me work around the undercooked bits of Airtable Automations (particularly how it handles empty or failed “find” actions), but Conditional Automation seems merely to stack on another half-baked layer.
Put it back in the oven until it’s got:
I hope other folks are having more success.
This is great. I have several scripts which are completely encapsulated by big old JS conditions, and it’s nice to be able to clean them up by offloading the conditional logic to a higher level in the automation, and just have the code be the core business logic.
I have to ask, though—does doing so give any kind of performance boost? Or might it be slower than just wrapping the Script Action in a big JS conditional?
Also, one little request for improvement: can you add current user/session data in the list for condition triggers, instead of just record and previous step data? (just as the current user is available in the Script API)
Also, a tip for others: Use the
REGEX_MATCH() function in a new formula column, and use that column in your conditional action to be able to use the power of regular expressions in addition to the basics like ‘contains’, ‘is’, ‘is not’, etc
Does that mean an Automation should only run if there’s a current user, meaning if no one has the base open the automation shouldn’t run? If a base has several collaborators and multiple people have the base open at once, which user’s data is supposed to carry through?
If you need “whoever made the change to the record which triggered an automation” you can use a Last Modified By field.
This is a MUST, especially for multistep automations! Duplicating as @Databaser suggested would be just as awesome
I agree, this is an alpha release. Since we are effectively working toward beta testing, please add in Nesting in addition to @Attaboy suggestions 1-3, at the very least if not also @Avana_Vana User data request.
We need to be thinking the same way for automation as when we do a Sort, Filter or ‘Group by’ in the view settings for the logic to maintain consistency, at the least. And, also for core scripting. This consistency is important because if the logic is dramatically different, like it is now, it is very difficult to decide which area of Airtable use to solve certain problems for consultants or developers and almost impossible for users.
After trying to solve some problems, I think it would have been better to get Data Validation right before adding conditional automation or perhaps release them together all using the same sorts of things that worked in the Logic updates for view Sort and Filter nesting.
Please let us know if you need us to help or just continue to support. Perhaps some of your enthusiasts should be converted to staff engineers. Some of the people in here could probably save AirTable a ton of headaches. Please remember to use your resources wisely as we all need Airtable to make these critical baby steps if Airtable is going to “walk on land” by summer.
Data Validation at the core, would make a lot of these automations streamlined. Imagine if we could trigger events off of data validations during and after field update instead of only on record update.
Finally, the ability to copy and paste bulk fields, with rows, between tables is a fantastic update that was release quietly. If I were Airtable, I’d be shouting that from the rooftop. That may have been the most understated feature release I have ever seen because it is the greatest quality of life improvement on the App I have seen since the start. So, we should also all celebrate the wins, too. :slightly_smiling_face:
Can we remove the limits until this is fixed? It’s really hard to know how to work with in limits without nesting or moving capabilities of conditions.
I could not agree more, Data Validation first, nothing is more important then Data Validation.
Mr. Airtable how many more requests do you need to get before you plan to offer Data Validation? This is ABC for a solid and reliable Database
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.