Make Iterator und Array Aggregator einfach erklärt

Wenn du in Make (früher: Integromat) zum ersten Mal über die Module Iterator und Array Aggregator stolperst, geht es dir wie fast allen: Das Szenario läuft ohne Fehler durch – aber statt 30 Zeilen landet nur eine einzige in deiner Tabelle. Genau dieses Problem lösen die beiden Module. In diesem Guide erfährst du, was sie tun, wann du welches brauchst, was jede einzelne Einstellung bedeutet – und welche Fehler dich am Ende echtes Geld kosten.

Eine Sache vorweg, damit du dich nicht wunderst: Makes Oberfläche gibt es nur auf Englisch. Eine deutsche Version der App existiert nicht (Stand Juli 2026). Die Module heißen also auch bei dir Iterator, Array Aggregator und Numeric Aggregator – ich benutze deshalb die englischen Original-Namen und erkläre sie auf Deutsch. So findest du jeden Begriff in deinem Make-Konto wieder.

Zuletzt aktualisiert: 27. Juli 2026, geprüft gegen die aktuelle Make-Oberfläche und Makes Modul-Referenz.

Die Kurzfassung

• Der Iterator nimmt ein Array (eine Liste in einem einzelnen Bundle) und zerlegt es in ein Bundle pro Eintrag. Jedes Modul danach läuft dann einmal pro Eintrag.
• Der Array Aggregator macht das Gegenteil: Er sammelt viele Bundles ein und verschmilzt sie zu einem Bundle mit einem Array darin.
• Der Numeric Aggregator verschmilzt viele Bundles zu einer einzigen Zahl – per SUM, AVG, COUNT, MAX oder MIN.
• Faustregel: So spät wie möglich zerlegen, so früh wie möglich wieder zusammenführen. Jedes Bundle, das durch dein Szenario wandert, vervielfacht deinen Credit-Verbrauch (dazu unten mehr).

Falls dir Begriffe wie Szenario und Modul noch nichts sagen: Lies zuerst was Make.com überhaupt ist – dieser Guide hier baut darauf auf.

Arrays und Bundles: das Vokabular in zwei Minuten

Ein Bundle ist das Datenpaket, das in Make von Modul zu Modul wandert – ein Datensatz, sozusagen. Ein Array ist eine Liste innerhalb eines Bundles. Du erkennst Arrays überall in Make an den eckigen Klammern im Mapping-Fenster:

Das Entscheidende: Ein Array ist dynamisch. Eine Bestellung hat mal 2 Positionen, mal 14. Eine Wetter-API liefert mal 40 Vorhersagen, mal 12. Du kannst dein Szenario nicht auf eine feste Anzahl bauen.

Make unterscheidet dabei zwei Sorten Arrays – und ein paar Einstellungen verhalten sich je nach Sorte unterschiedlich:

• Array aus Collections: Jeder Eintrag hat benannte Felder. Die Positionen einer Bestellung sind so ein Fall – jede hat Produktname, Menge, Preis.
• Primitives Array: Jeder Eintrag ist nur ein nackter Wert – eine Liste Zahlen ([4, 8, 15]) oder E-Mail-Adressen.

Die Falle, in die fast jeder einmal tappt

Im Mapping-Fenster kannst du direkt auf einen Eintrag unterhalb eines Arrays klicken. Das funktioniert – aber es mappt nur den ersten Eintrag der Liste, nicht alle:

Das ist die Ursache hinter dem Klassiker „es kommt immer nur eine Zeile an": kein Fehler, keine Warnung, einfach nur der erste Eintrag. Sobald du alle Einträge verarbeiten willst, musst du das Array zerlegen. Und genau dafür gibt es den Iterator.

Wann du einen Iterator brauchst – und wann nicht

Bevor du einen einbaust, prüf kurz, ob du überhaupt einen brauchst. Drei Fälle:

• Deine Daten kommen schon als einzelne Bundles an. Such- und Watch-Module (etwa Google Sheets Search Rows oder die meisten Trigger) geben von Haus aus ein Bundle pro Datensatz aus. Kein Iterator nötig – alles danach läuft ohnehin einmal pro Datensatz.
• Du brauchst nur eine Summe oder einen kombinierten Wert. Dann musst du oft gar nicht zerlegen: Funktionen wie sum(), length() und map() arbeiten direkt auf dem Array, mitten im Mapping-Feld – ohne ein einziges zusätzliches Modul.
• Du hast ein Array in einem Bundle und willst pro Eintrag etwas tun – eine Zeile schreiben, eine Nachricht senden, eine Rechnungsposition anlegen. Das ist der Iterator-Fall.

Falls du mitklicken willst und noch kein Make-Konto hast: Hier kannst du kostenlos eins anlegen.

Transparenz: Dieser Link ist ein Empfehlungs-Link (Affiliate). Nutzt du ihn, erhalten wir ggf. eine Provision – für dich ändert sich nichts am Preis.

So funktioniert der Iterator

Du findest den Iterator in Make unter den Tools (Flow Control). Er hat genau ein wichtiges Feld: Array – die Liste, die zerlegt werden soll. Dort mappst du dein Array hinein, mehr ist es nicht.

Beim Ausführen passiert dann Folgendes: Rein geht ein Bundle mit einem Array aus – sagen wir – 40 Einträgen. Raus kommen 40 einzelne Bundles, und jedes Modul nach dem Iterator läuft einmal pro Bundle:

Bei einem Array aus Collections trägt jedes Bundle die benannten Felder des Eintrags (Datum, Preis, …); bei einem primitiven Array trägt jedes Bundle den Eintrag als einzelnen Wert.

Der Schritt, den fast alle vergessen: Die Module nach dem Iterator musst du neu mappen – auf die Ausgabewerte des Iterators, nicht auf die Felder des ursprünglichen Moduls. Mappst du weiter auf das Original, bekommst du wieder nur den ersten Eintrag. Erst mit den Iterator-Werten füllen sich alle 40 Zeilen deiner Tabelle.

Das war der Iterator: Array rein, ein Bundle pro Eintrag raus. Der Aggregator ist das Spiegelbild – er setzt alles wieder zusammen:

Der Array Aggregator – jede Einstellung erklärt

Ein Aggregator wartet, bis alle ankommenden Bundles da sind, verschmilzt sie und schickt ein Bundle weiter. Der Array Aggregator ist die Allzweck-Variante: Sein Ergebnis ist ein Bundle mit einem Array darin. Seine Einstellungen im Einzelnen:

Source Module – das Modul, bei dem die Bundles entstehen, die du zusammenführen willst. Alles zwischen Source Module und Aggregator läuft einmal pro Bundle; der Aggregator sammelt die Ergebnisse ein. Wenn deine Aggregation komisch aussieht, prüf zuerst das: Ein falsches Source Module führt den falschen Ausschnitt zusammen.

Target structure type – wie die Einträge im Ergebnis-Array aussehen sollen. Mit Custom hakst du selbst an, welche Felder erhalten bleiben. Der eigentliche Profi-Trick: Wenn ein späteres Modul ein bestimmtes Array-Format erwartet (etwa ein Rechnungsmodul seine Rechnungspositionen), wähle als Target structure das Feld dieses Moduls – dann zeigt dir der Aggregator genau die Felder an, die dort gebraucht werden. Die meisten „mein Aggregator-Ergebnis passt nicht"-Probleme sind in Wahrheit ein Custom, wo die Ziel-Struktur hingehört hätte.

Group by – optionales Feld bzw. Formel. Statt eines großen Arrays gibt der Aggregator dann ein Bundle pro unterschiedlichem Wert aus. Beispiel: Bestellpositionen nach Lager gruppieren → ein zusammengefasstes Bundle pro Lager.

Stop processing after an empty aggregation – standardmäßig (Haken aus) gibt eine leere Aggregation trotzdem ein Bundle mit leerem Array aus, und das Szenario läuft weiter. Mit Haken stoppt die Route an dieser Stelle. Setz den Haken, wenn „mit leerer Liste weitermachen" Schaden anrichten würde – etwa eine leere Bestellbestätigung an einen Kunden.

Noch ein Hinweis zu primitiven Arrays: Der Array Aggregator gibt immer ein Array aus Collections aus – Einträge mit benannten Feldern. Erwartet ein späteres Modul ein pures Werte-Array (nur Zahlen, nur E-Mail-Adressen), zieh die Werte anschließend mit der Funktion map() aus dem Aggregator-Ergebnis. Und wenn du am Ende gar kein Array willst, sondern einen Text (etwa eine einzige Slack-Nachricht mit allen Positionen): Dafür gibt es den Text Aggregator, der alle Bundles mit einem Trennzeichen deiner Wahl zu einem String verbindet. Daneben existieren Table-, CSV- und JSON-Aggregatoren für genau diese Ausgabeformate – die Source-Module-Logik ist bei allen gleich.

Der Numeric Aggregator: SUM, AVG, COUNT, MAX und MIN

Der dritte im Bunde wird in vielen Tutorials unterschlagen, dabei ist er der einfachste: Der Numeric Aggregator verschmilzt viele Bundles zu einer einzigen Zahl. Du mappst einen Zahlenwert aus den ankommenden Bundles und wählst eine von fünf Funktionen:

Beispiel aus der Praxis: Eine Bestellung kommt mit einem Positionen-Array an. Iterator zerlegt es, ein Numeric Aggregator mit SUM auf Preis × Menge liefert dir die Bestellsumme als ein Bundle – fertig zum Mappen in die Rechnung. Willst du zusätzlich das teuerste Produkt für eine Upsell-Nachricht? Gleicher Aufbau, Funktion MAX auf den Preis. Wichtig: Ein Numeric Aggregator rechnet genau eine Funktion auf genau einem Wert – für Summe und Maximum brauchst du zwei.

Die vier klassischen Fehler

1. Ersten Eintrag gemappt statt iteriert. Symptom: keine Fehlermeldung, aber es kommt immer nur ein Datensatz an. Ursache: der Direkt-Klick auf den Array-Eintrag im Mapping-Fenster (siehe oben). Lösung: Iterator.

2. Zu spät aggregiert – oder ohne Grund iteriert. Jedes Modul zwischen Iterator und Aggregator läuft einmal pro Eintrag. Ein Array mit 50 Einträgen durch vier Module = 200 Credits pro Lauf; aggregierst du schon nach einem Modul, sind es 50. Und wenn du nie etwas pro Eintrag tun wolltest, sondern nur eine Summe brauchst: sum() im Mapping-Feld kostet null extra.

3. Nach dem Aggregator „fehlen" plötzlich Felder. Nach einem Aggregator sind die früheren Einzelfelder aus dem Mapping verschwunden – nur was du aggregiert hast, reist weiter, verpackt im Array. Das ist Absicht: Aus vielen Bundles wurde eins, Einzelwerte pro Bundle existieren nicht mehr. Lösung: Alle Felder, die du später brauchst, mit in die Aggregation aufnehmen – oder Werte mappen, die außerhalb der iterierten Strecke entstehen.

4. Nicht ans leere Array gedacht. Eine Bestellung ohne Positionen, ein Tag ohne neue Leads: Der Iterator gibt null Bundles aus – die Module danach laufen schlicht gar nicht. Je nach Aufbau fällt das wochenlang niemandem auf, oder ein Folgemodul verschluckt sich am leeren Array. Entscheide bewusst: leere Arrays früh per Filter aussortieren oder das Verhalten über Stop processing after an empty aggregation gezielt festlegen.

Was Iterator und Aggregator mit deiner Make-Rechnung machen

Kurze Begriffsbrücke, weil die meisten deutschen Tutorials älter sind: Make rechnet seit August 2025 nicht mehr in „Operations" ab, sondern in Credits. Die Umrechnung tut nicht weh: Eine Aktion – früher eine Operation – kostet weiterhin genau einen Credit. Die neue Einheit gibt es, weil du inzwischen KI-Modelle direkt in Make nutzen kannst – und deren Aktionen verbrauchen, in der Praxis sehen wir das in Kundenkonten täglich, auch krumme Bruchteile von Credits. Was du mit KI-Agenten in Make konkret bauen kannst, ist ein eigenes Thema.

Für Iterator und Aggregator lohnt es sich, diese Rechnung im Kopf zu haben:

• Der Iterator selbst zählt als eine Aktion – ein Credit – egal ob er 3 oder 3.000 Bundles ausgibt.
• Jedes Modul danach läuft einmal pro Bundle. 200 Einträge durch drei Module = 600 Credits, bei jedem einzelnen Lauf.
• Der Aggregator beendet die Multiplikation: Danach bist du zurück bei einem Bundle, und jedes Modul kostet wieder einen Credit.

Deshalb schlägt Szenario-Design jede Tarifwahl: Dasselbe Geschäftsergebnis, ein Modul früher aggregiert, kann deine monatliche Credit-Rechnung um ein Vielfaches senken. Was Credits in Euro bedeuten, steht in unserer Übersicht der Make-Preise und des Credit-Modells.

Das Muster im echten Leben: Bestellung mit Positionen

Am häufigsten begegnet dir das Ganze im E-Commerce. Eine Bestellung kommt herein – aus WooCommerce, Shopify oder deinem Shopsystem – und du weißt vorher nie, wie viele Produkte sie enthält. Die Positionen stecken als Array in der Bestellung. Das Muster:

1. Iterator zerlegt die Positionen.
2. Pro Position passiert etwas – eine Zeile ins Lager-Sheet, ein Bestandsabgleich.
3. Array Aggregator (Target structure: das Positionsfeld des Rechnungsmoduls) führt alles wieder zusammen.
4. Eine Rechnung entsteht in deiner Buchhaltung – mit allen Positionen.

Zerlegen, pro Eintrag handeln, zusammenführen, mit einem Bundle weiterarbeiten. Diese Sanduhr-Form erkennst du, einmal verstanden, in der Hälfte aller Szenarien wieder.

Fazit

Iterator: Array → Bundles. Array Aggregator: Bundles → Array. Numeric Aggregator: Bundles → eine Zahl (SUM, AVG, COUNT, MAX, MIN). Zerlege nur, wenn du pro Eintrag handeln musst, führe so früh wie möglich wieder zusammen und denk ans leere Array – dann sind deine Szenarien korrekt und günstig im Betrieb.

Du willst noch tiefer einsteigen? Das englische Original dieses Guides zeigt jeden Schritt mit Screenshots am kompletten Beispiel-Szenario.

Und wenn du solche Szenarien lieber bauen lässt – credit-effizient, mit Fehlerbehandlung und Dokumentation: Genau das machen wir.