Help

Re: Support for adding _single_ actions at the *end* of an Automation Repeating logic block?

Solved
Jump to Solution
69 0
cancel
Showing results for 
Search instead for 
Did you mean: 
amac
5 - Automation Enthusiast
5 - Automation Enthusiast

Use-case: As an Automation user, I have a use-case where I want to on a weekly scheduled (cron) basis query records that meet the criteria in one table and then create new child records of another table to the parent table and then email a consolidated report that includes the newly created childed records to the relevant recipients

Current outcome I can use the `Find` action to query for the specific and relevant records just fine, however, it is my understanding that once I use a `repeater logic` block, I can't "exit" the loop and append an Action outside of the repeater block once that the repeater has finished,


Is my understanding about this feature limitation correct?

Screenshot 2024-12-02 at 10.24.09 PM.png

 

Current work-around: I set up two separate Automations, both triggered by a cron schedule:

  1. The first Automation is triggered by its cron schedule, finds a list of records and then in a repeater block iterates thru each record in the list and creates a child record of a different table/object
  2. The second Automation is also triggered by a cron schedule and it runs after the first cron/Automation has run, it Finds/queries two different object/tables and then sends an email report digest with embedded grids from both those objects/tables in the Email body itself

 

1 Solution

Accepted Solutions
dilipborad
9 - Sun
9 - Sun

Hello @amac,
This is the same issue that I also noticed a couple of days ago.

Approach

I was trying to implement adding/updating multiple images to the attachment field based on the list data process.
The problem was I had a list of things that go through the loop which calls an API and updates the image to the Attachment field.
At the end that attachment field has multiple images are there.

Problem

Then I found that the attachment field replaces everything when I update the attachment field using the Automation script block within that loop. In the end, only one image is there because it replaces all the previous attached data from the attachment field when requested for an update.

How I solved it.

Just use my own tricks like on that loop every time get the last updated image URLs merge it with the new image URL and update it. Using this approach just update the attachment field multiple times but in the end, I get what I need.

Note: My implementation for these all things is done using Automation Script Block within that Repeat Step.

Why this is hard to directly implement on Airtable?

Let's see and check the approach of Make, It's a native platform for automation & integration.
As Airtable automation Repeat, they also have an Iterator. Which do the same things in their capacity and supported modules. 
But they support another type of concept which is called Aggregators, Which helps to combine data that we've processed during Repeatation(Iteration). They support Text, Array and JSON.
Make has those capabilities because the platform itself specializes in the purpose of automation.

But here on Airtable, there are lots of different things like Data, Automation, Interface and Forms.
Initially, there were Data parts only and later Airtable added these different parts match to the competition and don't rely on third-party tools.
I don't think Airtable are adding these Aggregators related to the same things because the usage of automation steps will be increased and ultimately they need to process more things. Also, remember that Airtable counts full automation as a single automation run. On the other end, Make is charged as per Operation based. 

My Recommendations

First, try the trick that I've applied.
I recommend you to use Internal Automation when there is basic logic is applied. Also, try to use Automation Script Block which itself has more capabilities for custom calculation and data formation.

If it's beyond that internal automation and script then use Make.

I hope you understand my concerns 👍

 

See Solution in Thread

4 Replies 4
dilipborad
9 - Sun
9 - Sun

Hello @amac,
This is the same issue that I also noticed a couple of days ago.

Approach

I was trying to implement adding/updating multiple images to the attachment field based on the list data process.
The problem was I had a list of things that go through the loop which calls an API and updates the image to the Attachment field.
At the end that attachment field has multiple images are there.

Problem

Then I found that the attachment field replaces everything when I update the attachment field using the Automation script block within that loop. In the end, only one image is there because it replaces all the previous attached data from the attachment field when requested for an update.

How I solved it.

Just use my own tricks like on that loop every time get the last updated image URLs merge it with the new image URL and update it. Using this approach just update the attachment field multiple times but in the end, I get what I need.

Note: My implementation for these all things is done using Automation Script Block within that Repeat Step.

Why this is hard to directly implement on Airtable?

Let's see and check the approach of Make, It's a native platform for automation & integration.
As Airtable automation Repeat, they also have an Iterator. Which do the same things in their capacity and supported modules. 
But they support another type of concept which is called Aggregators, Which helps to combine data that we've processed during Repeatation(Iteration). They support Text, Array and JSON.
Make has those capabilities because the platform itself specializes in the purpose of automation.

But here on Airtable, there are lots of different things like Data, Automation, Interface and Forms.
Initially, there were Data parts only and later Airtable added these different parts match to the competition and don't rely on third-party tools.
I don't think Airtable are adding these Aggregators related to the same things because the usage of automation steps will be increased and ultimately they need to process more things. Also, remember that Airtable counts full automation as a single automation run. On the other end, Make is charged as per Operation based. 

My Recommendations

First, try the trick that I've applied.
I recommend you to use Internal Automation when there is basic logic is applied. Also, try to use Automation Script Block which itself has more capabilities for custom calculation and data formation.

If it's beyond that internal automation and script then use Make.

I hope you understand my concerns 👍

 

ScottWorld
18 - Pluto
18 - Pluto

@amac 

Yes, unfortunately, this is one of the Top 5 biggest problems with Airtable’s automations.

Hoping they fix this problem soon!

In the meantime, for anybody reading this thread, the best solution is to outsource your Airtable automations to Make’s advanced automations for Airtable, which has none of Airtable’s limitations.

If you’ve never used Make before, I’ve assembled a bunch of Make training resources in this thread.

For example, here is one of the ways that you could instantly trigger a Make automation from Airtable.

I also give live demonstrations of how to use Make in many of my Airtable podcast appearances.

For example, in this video, I show how to work with Airtable arrays in Make.

Hope this helps! If you’d like to hire an expert Airtable consultant to help you with anything Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld 

Ha that's a nice workaround, thanks for posting it!

amac
5 - Automation Enthusiast
5 - Automation Enthusiast

Thanks @dilipborad and @ScottWorld for the suggestions and confirming what I was experiencing.

I am actually familiar with Make, and used it years ago back when it was called Integromat (🤯), that's interesting to see it evolve in its latest value prop into an extension for Airtable. I can def take a look

Also, regarding 'custom scripting ' -- I'm not against that approach @dilipborad , the current workspace I'm in is on a free plan (which unfortunately does not support running custom scripts esp thru automation), so I typically like to implement in a vanilla way that works on free level and can then scale nicely as the workspace commits to a paid plan