Hi everyone,
I’m stuck trying to build a scenario in Make and could use some help.
Here’s my setup:
-
Table 1: Requests for Quotation → order data (linked to Table 2)
-
Table 2: Products (linked to Table 1 and Table 3)
-
Table 3: Suppliers (linked to Table 2 and Table 1)
Goal: When a checkbox is marked in Table 1, I need to send an email. Since:
…I need to separate these relationships so that the scenario sends one email per supplier (Table 3), with the corresponding products (Table 2) from the related request (Table 1).
Problem: I’ve tried different approaches (using search, get, iterator, array aggregators, etc.), but the flow always breaks at some point. I’ve restructured the scenario multiple times to test different paths, but I can’t get it to work.
Any ideas or best practices for handling this type of one-to-many-to-many relationship in Make + Airtable?
Thanks in advance!
Hello @j.m_Tirab and Welcome to the Make Community!
So you have one RFQ, which is linked to multiple products and each product is linked to multiple suppliers. You need to email each supplier I presume with a list of all the products on that RFQ, but only those products which they actually supply?
On the Products table, if you don’t already, add a lookup field to get the Supplier name.
If your first module gets the RFQ, then next you can use an Iterator, followed by Airtable Get Record, followed by Array Aggregator.
Your Iterator will iterate on the linked Products.
Get Airtable record will get each Product in the iteration by using the iterator’s value.
The Array Aggregator will aggregate everything and you can group by Supplier.
The result of this would be multiple bundles, each with a Key for the Supplier, and array of collections containing the product data.
I am not 100% without trying it out if this would work for you, but hopefully that makes sense and hope it helps!
Hi Donald! I´ve considered what you´re saying, but I can´t get it to sent an email per supplier if that supplier has more than one product in the same record. I´ll share my current scenario with you in case you´re looking to resolve it.
Goal
From Airtable, when a Purchase Request (table Orders) is set to send, I need to send one single email per supplier. Each order contains multiple Generic Products (table Generics), and each generic can be linked to one or more Suppliers (table Suppliers).
Airtable schema
-
Orders
-
Order Number (text)
-
Requested Generics (link to Generics, multiple)
-
Order Details (long text, line breaks)
-
Send supplier emails (single select: “send”)
-
Email sent (Make) (date/time; Make writes now after successful sending)
-
Generics
-
Suppliers
Make scenario (current)
-
Airtable – Watch Records (Orders)
Filter formula (only picks candidates):
AND(
{Send supplier emails} = 'send',
{Email sent (Make)} = BLANK()
)
-
Airtable – Get a Record [Order]
-
Flow Control – Iterator (list: Order.Requested Generics[])
-
Airtable – Get a Record [Generic]
-
Flow Control – Iterator (list: Generic.Linked Suppliers[])
-
Airtable – Get a Record [Supplier] → here I get Supplier.Email (this yields 1 bundle per generic–supplier pair; e.g., 5 bundles if 3+2)
-
Flow Control – Array aggregator (A1)
-
Source module: Get a Record [Supplier]
-
Group by: trim(lower(73."Email")) (73 = the Supplier Get module)
-
Stop processing after an empty aggregation: Yes
(Goal: collapse 5 bundles down to 2 unique suppliers.)
-
Flow Control – Iterator (I1)
- Array:
A1 → Array[] (or Groups[], depending on UI)
(Goal: re-iterate over unique suppliers only.)
-
Email – Send an Email
-
To: I1.Key (this is the grouped supplier email)
-
Subject: “Quotation Request {{Order.Order Number}}”
-
Content Type: HTML
-
Body: my template; I insert {{Order.Order Details}} (long text; CSS white-space: pre-line)
-
Airtable – Update a Record (Orders)
- Set
{Email sent (Make)} = now (via date/time function picker), so the Watch filter will never match this record again.
What I expect
If an order involves 3 generics for Supplier A and 2 generics for Supplier B, I expect 2 emails total: one to A, one to B.
What actually happens
Emails are sent per generic (e.g., 5 emails), even though I configured an Array aggregator. In Run history I still see 5 bundles reaching the Email module.
Likely cause
The Email module is still attached to the pre-aggregation path (the first iterator’s cycle), or it’s reading an email value from the earlier Supplier module instead of using the aggregated Key from A1. I also hit “Invalid email address in parameter to” when the To field accidentally concatenated the supplier email with the order number (e.g., someone@mail.comPC-...), which breaks the address.
What I already tried
-
Group by with and without lower() / trim().
-
With and without an extra Text aggregator.
-
Placing the Email immediately after A1 (and after I1).
-
Verified I1.Key is just the email (no appended order number).
-
Still, Email shows 5 operations in the run (one per generic).
Questions
-
What’s the correct pattern to break out of the first iterator’s cycle and ensure the Email runs per unique supplier only? Is the sequence A1 → I1 → Email the right approach, or do I need a different structure (e.g., Router, distinct aggregator)?
-
Is there a recommended way to guarantee To = unique supplier email that cannot inherit the pre-aggregated bundles?
-
Any best practices to avoid the “Invalid email address in to” when grouping and mapping (e.g., always use I1.Key, or group by Supplier Record ID and then pick the first email in the group)?
Debug artifacts I can share
-
A1 (Array aggregator) config + output (should show #ops = #unique suppliers).
-
I1 (Iterator on A1) output showing Key.
-
Email Input → To (to confirm it’s I1.Key only).
-
Module operation counters (I’m seeing 5 on Email when it should be 2).
Bonus constraints
-
I want to keep the email body simple: the order-level Order Details is the same for all suppliers of that order, so I can insert it directly in the HTML (I do not need to build a per-supplier list unless necessary).
-
After successful send(s), I must set {Email sent (Make)} = now to block any future re-sends for that order.