Send mail to each record separately

Hey @Michal_Kubicek!
Welcome to the forums!

A limitation in Airtable’s automation suite is that it does not natively support iteration through arrays or lists of multiple records.

I think the most straightforward way to achieve what you’re looking to do is to create a formula field that returns a value once a certain condition is met.

Build an automation with a trigger to look for certain conditions. Point the trigger to look at the formula field and only continue when that formula field returns a certain value.

With this implementation, it will not matter if multiple records all trigger the automation simultaneously. They will all trigger independently and will not affect the automation runs of the other records.

It can be a bit challenging to properly describe how to set up and implement more complex solutions.
If you’d like a more in-depth walkthrough of what I just described, let me know, and I’d be happy to get that to you!

Welcome to the community, @Michal_Kubicek!

I cover the step-by-step process on how to solve your exact problem in this BuiltOnAir podcast episode:

p.s. If your company has a budget to hire an expert Airtable consultant to help you with your Airtable system, please feel free to contact me through my website: Airtable consulting — ScottWorld

@Michal_Kubicek

My solution above solves your problem & keeps everything in Airtable. But it does add extra clutter to your base.

Alternatively, for a cleaner & easier way of doing this, this is just a simple 2-step automation in Make, which always loops through your found records to send individual emails. This is what it would look like:

Given a large enough data set and a fast enough pace, this approach will deeply matter because automation runs are finite. :winking_face:

Do you want to customize the email to each recipient? For example, do you need to include the recipient’s name or other unique info?

If not, you could use one email and bcc the recipients. This would result in one email, but recipients would not see other email addresses.

If you want to use native Airtable email automations, keep in mind that there are rate limits to the number of emails that can be sent at the same time. For example, there is a limit of sending 1 email per second when using gmail, per this support page.

I sometimes forget about the enterprise Automation limits versus the Pro/Plus/Free plans. :man_facepalming:

Yeah, me too. However, my comment has little to do with the plans because I’ve seen this disaster unfold in big and small Airtable accounts.

You think the ceiling is pretty high, but it’s not; every aspect of a no-code system should be scrutinized concerning resources and performance. Scalability slices across many elements, and few developers understand that automations and API calls are central to the container instance that Airtable runs in. As such, even a [seemingly] innocuous but overloaded high-octane email burst has the ability to make Airtable unusable for many users in that account. This is why @kuovonne called out yet another possible misstep designed to protect actual human users.

I’m kinda loopy and coming off of general anesthesia this morning, so I might be kinda ehhh, but I have a curiosity if you’re willing to indulge me.

At this point, beyond adding smaller app integrations for automation action, Airtable is coming to the point where it will be necessary to introduce an iteration action to continue to scale properly.

You’re the API wizard in these parts. Do you predict that there will be critical bottlenecks in how we’ll be able to utilize it or just bottlenecks in general?

More accurately… what do you think the bottlenecks will be?

It’s a rather open-ended question, but I’m just not familiar enough with the backend to really be more specific.

Ha ha! No one is that familiar enough with Airtable’s backend. There are many mysteries and we can only speculate in most cases. However, they have confirmed some of the speculations concerning performance, an issue that has plagued successful apps for years.

Bottlenecks are typically self-inflicted wounds caused by no-coders who want instant integration gratification. The use of glue-factory services such as Zapier allow no-coders to [seemingly] scale solutions, but at a cost that usually creates more pressure on the Airtable instance than would otherwise be the case if a clean event-driven approach were fabricated.

We can’t blame Airtable’s no-code customers for this; the event architecture of Airtable has been been sluggishly exposed over the past few years.

Certainly, an iteration component in Airtable’s automation feature would be far better than iterations performed in Zapier because Zapier recipes typically fire amidst a barrage of polling requests to the API. This insanity could/should be avoided and performing iterations closer to the data would potentially eliminate hundreds of thousands of API requests.

It’s in Airtable’s best interest to give Zapier a comprehensive event architecture or obsolete Zapier by making it all possible inside the Airtable SDK via script automations. There is already evidence low-coders are avoiding glue-factory solutions through clever script automations.