Flow control needed in Airtable Automations

Airtable Automations need flow control options to decide whether I am processing a bunch of records at the same time or one by one. Integromat has flow control and I can decide how many records are processed in one cycle, but still only one record is processed if that flow handles 1 record only.

In Airtable on the other hand, seems a bunch of records fields gets updated and it doesn’t seem to me it is sequential but some is running in parallel. Maybe I am wrong, maybe it’s all going one by one and maybe it’s just the timer issue as mentioned above.

However, I get another problem with doing deduplication of records using automation in Airtable. I have setup a helper table to check duplicates of records in main table (it’s done through linking the tables back and forth.)
It works fine, except when the main table is filled in by another (unrelated) earlier automation because when multiple records are filled in, it triggers my deduplication automation at the same time for many records. Then the deduplication automation creating the links to deduplication helper table runs on all the created records at the same time and that causes the back-links from the deduplication table assigned to the individual record and not the the first top-most record (which is how this deduplication trick works in Airtable and which enables me to see duplicate records through roll-up function).

Another issue with different unrelated automation being too fast. While it was working perfectly and showing no errors in the flow, yet it was filling blank values because the underlying values (that the automation was supposed to work with) were not ready in the fields yet as the values were coming from a calculation and a different earlier part of the same automation.

I solved it by breaking down the flow into 2 automations as a workaround.

So as I mentioned in another other post, the two things I wish Airtable adds to Automation:

  • Delay/Pause between the steps
  • Flow control (how many records are going to be processed in one go).

You are correct that there is no sequential processing in Airtable’s Automations. It processes records in a random & unpredictable order, and possibly multiple records simultaneously. And they offer no way of sorting records into the order that you want your records to be processed.

As you mentioned, the good news is that until Airtable implements this, you can achieve your desired results by using a professional automation & integration tool like Make.com.

You may also be able to achieve your desired results by writing a script, but I do not know JavaScript so somebody else would need to advise on that front.

p.s. You keep mentioning Integromat in many of your posts, but Integromat transitioned to Make over a year ago in February 2022. If you’re still using Integromat, you only have until September 30, 2023 to migrate your scenarios over to Make and update all of your webhooks to Make URLs as well. Integromat is fully shutting down on September 30, 2023, and they will be shutting down all of their webhooks/mailhooks too. So if you haven’t already made the transition, I would recommend to start doing it sooner rather than later.

A bit off-topic:
Does Integromat now watch changes in field names? I know it was an issue before so if field name changed the mapping had to be refreshed. Zapier was able to see changes.

Unfortunately, Make doesn’t recognize field name changes, but each Airtable module gives the advanced option to map by what they call “Column IDs” (instead of “Field IDs”). It’s frustrating that Make invents their own terms for things like this in Airtable (such as “Smart Links” instead of “typecast”), and it’s also frustrating that they don’t just monitor for field name changes… because it can be very challenging to write an entire scenario using only Field IDs, which is what they require people to do. Make definitely is not as polished as Zapier in some regards.

Make interface is addictive. Once learning iPhone is no way go back to feature phone with keyboard that’s how I feel about Zapier, being just Microsoft Power Automate without the headaches of building a space shuttle when all I need is a snow sled.

You mentioned Column IDs/ Field IDs. I always wanted to find out what it does. So can I reference the Column IDs instead of field names and then it will not break if I use that?

If that’s the case, why wouldn’t make organize the whole Airtable integration so that it allows selecting the field names but links the fields by their Column IDs. My guess it’s just literally a few lines of code when you compare the programming effort requires for everything else they already done.

My guess is because when Make/Integromat first got started, the Airtable API that they used did not support field IDs, only field names.

On the other hand, Zapier had a special relationship with Airtable and had access to its own special non-public API that probably had more features.

Make could create new modules that leverage table/view/field IDs, but they would need to be new modules and scenarios would need to be migrated.

1 Like

What Make function are you referring to ? If you for instance use a Create Module and bind some data… go into Airtable and change column names, then go back into Make and re-run the scenario, the integration will still work.

The actual Label will still show the old name until you click refresh but it will indeed still work and bind to the correct field.

This was not always the case with older versions of the Make / Airtable Modules


@Lorenzo Oh wow, really?! This is awesome to hear! I haven’t tested this recently, due to previous failures in Make. I’ve gotta try this out! Thank you!

Although the problems I’ve had in the past weren’t the hardcoded field names in the “Create” module… it was the “field mapping” that pulls its data from previous Airtable modules in the scenario.

And yes, as you mentioned, there seems to have been many “silent upgrades” to the Airtable modules… even though they cosmetically look the same. I can actually tell the difference in modules when converting people’s Airtable modules from the old connection method (API key) to the new connection methods (oAuth / Personal Access Token). Upon converting a module to the new connection, the “older” Airtable modules forget the table name — and the table name has to be reselected again. The “newer” Airtable modules do not forget anything.

Yeah I am not a fan of silent updates. I wish they had built-in release notes of some sort.