I have the folowing scenario in Make.com (Shoutout ScottWorld). In the event, I am finding the invitee’s emails. I then iterate those and seach my contacts table for each email. I then want to pass through a list of the Airtable record ids into the final step but instead it overrides the linked record instead of using all contacts found.
How can I fix this?
Here is the iterator:
Here is the Search:
Here is the array aggregator:
Here is the update record:
Hi @ben,
Thanks for the shoutout to me & my Make referral link! 
This is kind of a tricky problem to solve, but the solution shows off the true power of Make.
The problem here is that once you iterate your array in module #24, Make treats each iteration of the array as a brand new bundle that will be completely processed by the rest of the iterator’s path. (In your case, you only have one path, so the iterator’s path is the rest of the scenario.)
So even though you’re trying to aggregate the search module (#14) with the array aggregator (#27), it’s too late at that point because the iterator module is overriding both your search & aggregator modules.
In other words, the iterator module wants to finish each one of its bundles through the rest of the scenario, so it’s pushing each one of its bundles all the way through to the very end of the scenario. (It’s doing this because you only have one path. You could solve this problem with multiple paths, which I will show you how to do below.)
So by the time you get to your search module (#14), it is only searching on ONE contact at a time. This is actually EXACTLY what you want for your search! So this is great news so far!
But after the search, the aggregator module (#27) only has one record to aggregate, because the iterator module is still taking priority over the rest of the scenario. The iterator module is still pushing only that ONE CONTACT through the rest of the scenario. So the iterator module is overriding the aggregator module, and you’re only aggregating one contact at a time instead of aggregating 6 contacts together.
You can tell that this is a problem because the array aggregator is outputting 6 different outputs instead of 1 output, which is what you really want.
So, by the time you get to the final “Update A Record” module (#5), you only have one Contact ID that you can update your record with. You have 6 Contact ID’s, but they’re coming through at 6 different times because of the iterator module.
You can see that the “update” module is giving you 6 outputs instead of 1 output, so it’s updating Airtable 6 different times. Each time it is updating Airtable, it is overriding the previous contact ID with the newest contact ID.
If you look at your activity history in Airtable, you will see that all 6 contact IDs came into Airtable, but each one overrides the previous one, because they each came into Airtable one-at-a-time.
There might be more than one way of solving this problem, but the way that I solve this problem is by splitting the scenario into multiple paths:
So what happens here is that only the 2nd path will run multiple times (because of the iterator). Both the 1st and the 3rd path will run ONLY ONCE, which will give you the results that you’re looking for.
You can see screenshots of this in the messages below. (Discourse only lets us upload 5 screenshots per message, so there are 2 messages below.)
p.s. In my scenario, I’m creating a new record in Airtable… so your scenario will be slightly different than mine, since you’re updating an existing record.
This worked perfectly! Thank you so much Scott! Amazing how you knew exactly what to do
@ben Haha! You’re welcome! 
It’s amazing that you asked this very specific question, because a client of mine needed this exact same scenario a few weeks ago. 
Update on this topic:
I give a deep dive on simple & complex arrays in Airtable on this episode of the BuiltOnAir podcast:
