Wow — looping in automations is finally here!
It has several limitations, but this is still a big step in the right direction:
Thanks to @ben for alerting me to this! 
I wonder how much this will affect people signing up for Zapier and Make, since this is one of the big reasons that people use those tools.
1 Like
The only thing I miss is branching now. So that will still be for Zapier/Make I guess.
1 Like
Um, lots.
You may recall this post (pre-covid) where I said it’s only a matter of time before the vendors wake up and realize the glue factories are raising the total cost of ownership making it impractical to sustain a profit margin the investors expect.
4 Likes
Hey, this looks interesting - although I live my life entirely in scripts so may be of little use to me (and if anything, using no-code actions often introduces problems/delays/extra-steps when debugging my scripts)
In checking my Automations now, I’m still on the previous version so can’t test this new feature yet.
1 Like
I see two big advantages of using Airtable’s native actions instead of scripting. (1) Automation scripts must hardcode table and field names or IDs. Hardcoding names means the script breaks when names change. Hardcoding IDs makes the script harder to read and if someone deletes a field and recreates it instead of restoring it, the script breaks. (2) Airtable’s dependency lists are unaware of fields used in scripts, but are aware of fields used in native actions. This makes maintenance much easier.
4 Likes
There’s another element - an elephant in the room - table and field names should be anchored for many reasons other than script dependencies. If you adopt the idea that you’ll use internal automation recipes so that things won’t break as easily, this is not always a good strategy because it actually promotes behaviours that shouldn’t be okay.
When airbags became prevalent, automobile injuries and their maming nature rose massively for two reasons:
- The bags sustain life, where they would otherwise be snuffed out.
- The bags created a sense of undeserved confidence; that a crash may not be injurious or a big deal any more.
The same happened with skiing helmets. Once they were broadly adopted, ski injuries rose significantly because skiers felt impervious to injury and they ski faster and take more risks.
Adopting a similar posture with subliminal protection in your Airtable solutions may result in unanticipated data injuries. Businesses should not allow their user base to become complacent with the idea that unmanaged change is okay because there will be dependencies somewhere and your data will be injured, perhaps severly.
And yet we still have airbags, and helmets, and seat-belts, and other safety devices. Some people may see them as an excuse to participate in riskier behavior. Others will continue to act responsibly yet still use these safety devices because they know there factors out of their control.
I am not advocating for unmanaged change. Rather, I am saying that these are features that can help manage change.
The data for automobile and skier injuries doesn’t reflect this. I have a hunch any lack of policy or controls concerning table and field name changes would result in a higher incidence of issues. After all, it only takes one script that uses names to toss a monkey into the wrench. Automations are just one facet of exposure from change.
Or stated another way -
These are features that accommodate behaviors that could lead to potentially catastrophic outcomes.
It’s great that this new feature is impervious to change. Certainly it should be used. I wonder how this impacts runs and computational impact on Airtable itself.
Um. That’s not what I said.
Most loops will probably have 100 or less iterations, since most people will use this with the “Find Records” action. If you use a list output from scripting, you can get 8000 iterations.
Per the documentation, runs are charged on a per trigger basis, so looping across 8000 records doesn’t cost the user anything extra.
The actual computational impact on Airtable itself is much harder to determine. I wonder if Airtable thinks that people who could loop over more than 100 records would know how to write scripts anyway. If so, I disagree with this guess.
Aside from the fact that @bfrench and @Kuovonne could use their own channel (
), the looping feature is now available for me! Testing time 
Edit: only appears in newly created bases for me (for now)
2 Likes
Certainly, we have seen many cases where Airtable themselves would struggle to use this feature in practice. But we also have years of experience with Airtable adding a seemingly ideal feature and then we discover something about it just isn’t right. Anything involving loops implemented as a black box has a much higher probability of incurring costs that are unseen until they aren’t.
Great feature! Tread with caution.
I’m seeing inconsistent results when using a list output by a script. A flat array works okay. An array of objects worked as expected the first time, but changing the shape of the objects broke things, even when restarting from scratch and retesting everything individually.
I now have this in:
- Brand new bases
- Bases with one or no existing automations
It doesn’t show in my bases that already have other (typically complicated) automations in.
Very excited to start simplifying some of my existing automations, I loathe using the 2x automations to do one thing (trigger, then run).
1 Like
Yes, same here.
Regarding the limitation of 100 records (or 8000 records when scripting), it looks like there is a little hidden gem built in here.
According to this support page, if you use an array of linked records (from a linked record field) as your input, you also get the increased 8,000 record limit!
Is there an upper limit related to the number of items that can be looped through in an input list? Yes, there is a limit of 8000 items per input list. This limit might be reached in automations that contain input lists that reference arrays from scripting outputs but can also apply to automations that use a linked record or user field as an input list source. Automations using the Find records action as an input list source are already limited to 100 records per action, which means that it will not exceed this limit.
So bizarre. It says this on their support page:
The Test automation button will be disabled once a repeating group has been added to the automation. You’ll want to use the Test step option next to each step of the automation instead.
Same here. I get the sense that it was designed by people who don’t use scripts or complex Make recipes to automate Airtable processes.
I’m gonna go out on a limb and call it early. This feature will ultimately be a really good idea on paper but a really poor [underlying] implementation.
2 Likes