„Apply to each“ in Power Automate: die Schleife verstehen, steuern und vermeiden

„Apply to each", in der deutschen Oberfläche „Auf alle anwenden", ist die Schleife von Power Automate. Sie führt die enthaltenen Schritte für jedes Element einer Liste einzeln aus, für jede E-Mail, jede Zeile, jeden Anhang.

Zwei Eigenheiten machen sie zum meistdiskutierten Baustein der Plattform. Sie erscheint oft von selbst, ohne dass jemand sie eingefügt hat. Und sie ist der häufigste Grund, warum Flows langsam werden. Beides hat dieselbe Ursache, und beides lässt sich steuern.

Warum erscheint „Apply to each" von selbst?

Power Automate fügt die Schleife automatisch ein, sobald Sie einen dynamischen Inhalt verwenden, der technisch eine Liste ist. Das gilt auch dann, wenn Sie nur ein einzelnes Element erwarten.

Der Klassiker ist die SharePoint-Abfrage. Sie liefert immer ein Array, selbst bei genau einem Treffer. Der Designer wickelt den Folgeschritt daraufhin in ein „Auf alle anwenden".

Wer das einzelne Element gezielt ansprechen will, greift mit einem Ausdruck darauf zu. Diese Ausdrücke stammen aus dem Expression-Cookbook von Microsoft:

1first(body('Elemente_abrufen')?['value'])?['Title']
2
3if(empty(body('Elemente_abrufen')?['value']), null, first(body('Elemente_abrufen')?['value']))
4
5length(body('Elemente_abrufen')?['value'])
Copy

Der Aktionsname in body() wird mit Unterstrichen statt Leerzeichen geschrieben. first() auf einem leeren Array liefert null und keinen Fehler, deshalb die Prüfung mit empty() in der zweiten Zeile.

Noch sauberer ist es, die Liste vorher serverseitig auf einen Treffer zu reduzieren. Bei SharePoint übernimmt das die OData-Filterabfrage im Feld „Filter Query":

1Status eq 'Offen' and Kategorie eq 'Rechnung'
Copy

Leerzeichen in Spaltennamen ersetzen Sie dort durch _x0020_, also etwa Start_x0020_Date.

Was macht die Schleife langsam und was hilft?

Die Schleife läuft standardmäßig sequenziell, also ein Element nach dem anderen, und genau das kostet die meiste Zeit. In den Einstellungen der Aktion aktivieren Sie „Nebenläufigkeitssteuerung" und setzen den Parallelitätsgrad auf einen Wert zwischen 1 und 50.

Microsoft dokumentiert für einen Testlauf über vier Elemente diese Werte:

Arraylänge | Parallelitätsgrad | Laufzeit der Schleife

Arraylänge: 4 · Parallelitätsgrad: aus · Laufzeit der Schleife: 21 Sekunden

Arraylänge: 4 · Parallelitätsgrad: 2 · Laufzeit der Schleife: 11 Sekunden

Arraylänge: 4 · Parallelitätsgrad: 4 · Laufzeit der Schleife: 6 Sekunden

Arraylänge: 4 · Parallelitätsgrad: 6 · Laufzeit der Schleife: 6 Sekunden

Quelle: Optimize flows with parallel execution and concurrency.

Der Sprung von 4 auf 6 bringt nichts mehr. Ein hoher Wert beschleunigt also nicht beliebig, weil Aufteilung, Warteschlange und das angerufene System eigene Zeit kosten.

Vorsicht ist geboten, wenn die Reihenfolge zählt oder wenn in der Schleife eine Variable beschrieben wird. Gleichzeitige Schreibzugriffe überholen sich dann gegenseitig.

Welche Grenzen gelten für die Schleife?

Vier Grenzwerte entscheiden darüber, ob ein Flow bei großen Datenmengen durchläuft oder abbricht. Sie stehen in den Limits von Cloud-Flows:

Grenze | Wert | Bedeutung im Flow

Grenze: Elemente je „Auf alle anwenden" · Wert: 5.000 bei „Low", sonst 100.000 · Bedeutung im Flow: Mehr Elemente verarbeitet eine Schleife in einem Lauf nicht

Grenze: Parallelitätsgrad · Wert: 1 bis 50, Standard 1 · Bedeutung im Flow: Standard 1 bedeutet: streng nacheinander

Grenze: Verschachtelte Schleifen · Wert: immer sequenziell · Bedeutung im Flow: Nebenläufigkeit wirkt nur auf der obersten Ebene

Grenze: Paginierte Elemente · Wert: 5.000 bei „Low", sonst 100.000 · Bedeutung im Flow: Obergrenze für den Schwellenwert der Paginierung

„Low" bezeichnet dabei das niedrigste Leistungsprofil. Alle anderen Profile erlauben den höheren Wert.

Dazu kommt das Kontingent Ihrer Lizenz. Jeder Schritt innerhalb der Schleife zählt als eigene Aktion. Bei 500 Elementen und drei Schritten sind das rund 1.500 Aktionen aus dem Tagesbudget. Schlanke Schleifen sparen also bares Geld.

Warum verarbeitet die Schleife nur 100 Elemente?

Der Grund liegt nicht in der Schleife, sondern im vorgelagerten Abfrageschritt. Die SharePoint-Aktion „Elemente abrufen" liefert laut Microsoft-Dokumentation standardmäßig genau 100 Elemente.

Zwei Stellschrauben beheben das:

1. Unter „Erweiterte Optionen" den Wert „Top Count" erhöhen. Das Maximum liegt bei 5.000 und entspricht der Listenansichtsschwelle.
2. In den Einstellungen der Aktion die Paginierung einschalten und einen Schwellenwert eintragen. Der maximal konfigurierbare Schwellenwert beträgt 100.000.

Der Schwellenwert wird intern auf Vielfache der Seitengröße aufgerundet. Tragen Sie bei einer Seitengröße von 5.000 den Wert 7.000 ein, liefert die Aktion 10.000 Zeilen.

Wie vermeiden Sie die Schleife ganz?

Die schnellste Schleife ist die, die nie läuft, und drei Datenoperationen ersetzen sie in vielen Fällen. „Array filtern" reduziert eine Liste ohne Schleife, „Auswählen" formt alle Elemente in einem Schritt um, „Verbinden" macht daraus einen Text.

Muster | Aktionen bei 500 Elementen | Wann geeignet

Muster: „Auf alle anwenden" mit drei Schritten · Aktionen bei 500 Elementen: rund 1.500 · Wann geeignet: Jedes Element löst einen eigenen Aufruf aus, etwa eine Datei-Kopie

Muster: „Array filtern", „Auswählen", „Verbinden" · Aktionen bei 500 Elementen: 3 · Wann geeignet: Filtern, Umformen und Zusammenfassen, etwa für eine Sammel-E-Mail

Muster: Stapelverarbeitung über die Connector-API · Aktionen bei 500 Elementen: 1 Aufruf je Stapel · Wann geeignet: Massenanlage oder Massenupdate in Dataverse und SharePoint

So sieht das Muster im Code-Editor des Flows aus. Die drei Aktionen ersetzen eine Schleife über offene Vorgänge und erzeugen eine fertige Textliste:

1{
2  "Filter_Array": {
3    "type": "Query",
4    "inputs": {
5      "from": "@body('Elemente_abrufen')?['value']",
6      "where": "@equals(item()?['Status'], 'Offen')"
7    },
8    "runAfter": {}
9  },
10  "Select_Zeilen": {
11    "type": "Select",
12    "inputs": {
13      "from": "@body('Filter_Array')",
14      "select": "@concat(item()?['Title'], ' | ', item()?['Faellig'])"
15    },
16    "runAfter": { "Filter_Array": ["Succeeded"] }
17  },
18  "Join_Liste": {
19    "type": "Join",
20    "inputs": {
21      "from": "@body('Select_Zeilen')",
22      "joinWith": "\n"
23    },
24    "runAfter": { "Select_Zeilen": ["Succeeded"] }
25  }
26}
Copy

Query ist der interne Typ der Aktion „Array filtern". Beachten Sie, dass der Textvergleich in „Array filtern" zwischen Groß- und Kleinschreibung unterscheidet.

Ein Flow, der erst filtert, dann umformt und das Ergebnis in einem Schritt verschickt, braucht drei Aktionen statt hunderter. Genau diese Sorte Handwerk vermitteln wir in der Power-Automate-Beratung. Den Schwester-Baustein der deutschen Oberfläche erklärt unser Beitrag zu „Verfassen" (Compose).

Typische Fehler und Ursachen

Fünf Fehlerbilder treten bei „Auf alle anwenden" regelmäßig auf, und alle fünf haben eine dokumentierte Ursache.

Die Schleife verarbeitet nur 100 Elemente. Ursache: Der Abfrageschritt liefert nur die erste Seite, bei „Elemente abrufen" sind das 100 Einträge. Lösung: „Top Count" erhöhen und die Paginierung mit Schwellenwert aktivieren. Quelle: Get items und Get files.

Die Parallelität wirkt in der inneren Schleife nicht. Ursache: Die Nebenläufigkeitssteuerung greift nur auf der obersten Ebene, verschachtelte Schleifen laufen immer sequenziell. Lösung: Die Datenstruktur per „Auswählen" flach ziehen oder die innere Verarbeitung in einen untergeordneten Flow auslagern. Quelle: Parallel execution and concurrency.

Der Flow meldet „429 TooManyRequests". Ursache: Der Parallelitätsgrad liegt über dem, was der angesprochene Connector zulässt. Lösung: Den Grad in der Nebenläufigkeitssteuerung schrittweise senken. Quelle: Too many requests error.

Eine Variable enthält nach der Schleife falsche Werte. Ursache: Bei aktivierter Parallelität schreiben mehrere Durchläufe gleichzeitig in dieselbe Variable. Lösung: Entweder sequenziell arbeiten oder das Ergebnis ohne Variable über „Auswählen" und „Verbinden" erzeugen. Quelle: Parallel execution and concurrency.

Der Lauf bricht bei sehr großen Listen ab. Ursache: Die Schleife verarbeitet höchstens 5.000 Elemente im Profil „Low" und 100.000 in allen anderen Profilen. Lösung: Vorher filtern oder die Menge auf mehrere Läufe verteilen. Quelle: Limits of automated, scheduled, and instant flows.

Häufige Fragen zu „Apply to each"

Wie bekomme ich einen Wert aus der Schleife heraus?

Der übliche Weg führt über eine Variable: vor der Schleife initialisieren, innen anhängen oder hochzählen, danach weiterverwenden. Bei aktivierter Parallelität ist das riskant, weil sich gleichzeitige Schreibzugriffe überholen. Dann arbeiten Sie sequenziell oder erzeugen das Ergebnis über „Auswählen" und „Verbinden" ganz ohne Variable.

Warum verarbeitet meine Schleife nur 100 Elemente?

Weil der vorgelagerte Abfrageschritt nur die erste Seite liefert. Die Lösung liegt im Abfrageschritt, nicht in der Schleife: „Top Count" erhöhen und die Paginierung mit passendem Schwellenwert aktivieren.

Kann ich Schleifen ineinander verschachteln?

Ja, das ist möglich, etwa für Bestellungen mit Positionen. Die Aktionszahl multipliziert sich dabei, und die innere Schleife läuft immer sequenziell. Bewährt hat sich, die innere Verarbeitung in einen untergeordneten Flow auszulagern oder die Daten vorher per „Auswählen" so umzuformen, dass eine Ebene reicht.