Apply-to-each-Limits und Paginierung in Power Automate: Wie die 100.000-Iterationsgrenze funktioniert und wie Sie sie umgehen.
Ein Flow bricht mit einem kryptischen Fehler ab, sobald eine SharePoint-Liste, eine Dataverse-Tabelle oder ein Excel-Bereich eine bestimmte Größe überschreitet. Dahinter steckt fast immer eine der eingebauten Schleifen- und Paginierungsgrenzen von Power Automate.
Die bekannteste ist die 100.000er-Grenze für Apply-to-each-Schleifen und paginierte Elemente. Sie bleibt lange unsichtbar, weil die meisten Listen kleiner sind. Sie schlägt dann bei genau den Prozessen zu, die am wichtigsten sind: Massenimporte, Jahresabschlüsse, Migrationen.
Dieser Beitrag zeigt die konkreten Grenzwerte, den Weg zur Paginierung und die Muster für sehr große Datenmengen. Alle Zahlen stammen aus der Microsoft-Dokumentation und sind dort verlinkt.
Fünf Werte entscheiden darüber, ob ein Lauf durchläuft oder abbricht, und alle fünf gelten je Flowausführung. Microsoft führt sie in den Grenzwerten für automatisierte, geplante und Direktflows:
Grenze | Wert | Bedeutung im Flow
Grenze: Elemente je „Auf alle anwenden" · Wert: 5.000 bei „Niedrig", 100.000 bei allen anderen · Bedeutung im Flow: Mehr Arrayelemente verarbeitet eine Schleife in einem Lauf nicht
Grenze: Paginierte Elemente · Wert: 5.000 bei „Niedrig", 100.000 bei allen anderen · Bedeutung im Flow: Obergrenze für den Schwellenwert der Paginierung
Grenze: Nach Elementen aufteilen (SplitOn) · Wert: 5.000 bei „Niedrig", 100.000 sonst, aber 100 mit Trigger-Parallelität · Bedeutung im Flow: Der Trigger zerlegt ein Array in einzelne Flowinstanzen
Grenze: Until-Iterationen · Wert: Standard 60, Maximum 5.000 · Bedeutung im Flow: Obergrenze für die Schleife „Bis"
Grenze: Parallelität bei „Auf alle anwenden" · Wert: Standard 1, einstellbar 1 bis 50 · Bedeutung im Flow: Gleichzeitig laufende Iterationen einer Schleife
Beachten Sie den Sonderfall bei SplitOn. Schalten Sie am Trigger die Parallelität ein, sinkt das Limit von 100.000 auf 100 Elemente.
Das Leistungsprofil richtet sich nach der Lizenz des Flow-Besitzers und entscheidet, ob 5.000 oder 100.000 gelten. Microsoft ordnet die Pläne in derselben Übersicht zu:
Profil | Pläne (Auszug) | Elemente je Schleife
Profil: Niedrig · Pläne (Auszug): Free, Microsoft-365-Pläne, Power Apps Plan 1, alle Testlizenzen · Elemente je Schleife: 5.000
Profil: Mittel · Pläne (Auszug): Power Automate Premium, Power Automate Plan 2, Power Apps Plan 2, Dynamics-365-Enterprise-Pläne · Elemente je Schleife: 100.000
Profil: Hoch · Pläne (Auszug): Power Automate Process, Power Automate per Flow · Elemente je Schleife: 100.000
Profil: Unlimited Extended · Pläne (Auszug): Pay-as-you-go-Flows · Elemente je Schleife: 100.000
Ein Flow übernimmt das Profil seines Besitzers. Verlässt der ursprüngliche Besitzer die Organisation, fällt der Flow laut Dokumentation auf das Profil „Niedrig" zurück. Damit halbiert sich Ihre Grenze auf 5.000, ohne dass jemand etwas geändert hat.
Der Flow bricht mit genau diesem Fehlercode ab, sobald eine Apply-to-each-Schleife ihre maximale Iterationszahl überschreitet. Die Fehlercodereferenz für Cloudflüsse nennt drei häufige Ursachen:
Im Ausführungsverlauf sehen Sie den Fehler direkt an der betroffenen Schleifenaktion. Unter Analysen auf der Flow-Details-Seite prüfen Sie zusätzlich die tatsächliche Aktionszahl eines Laufs.
Die Paginierung schalten Sie in den Aktionseinstellungen ein und tragen dort einen Schwellenwert bis 100.000 ein. Für Zeilen auflisten beschreibt die Dokumentation zu Zeilenlisten in Flows den Weg im neuen Designer:
Schritt | Ort in der Oberfläche | Eintrag
Schritt: 1 · Ort in der Oberfläche: Aktionskarte Zeilen auflisten auswählen · Eintrag: keiner
Schritt: 2 · Ort in der Oberfläche: Linker Bereich, Registerkarte Einstellungen · Eintrag: Abschnitt Netzwerk öffnen
Schritt: 3 · Ort in der Oberfläche: Schieberegler Paginierung · Eintrag: auf Ein
Schritt: 4 · Ort in der Oberfläche: Feld Schwellenwert · Eintrag: Zahl bis maximal 100.000
Intern rundet Power Automate den Wert auf volle Vielfache der Seitengröße auf. Tragen Sie 7.000 ein und die Seitengröße beträgt 5.000, liefert die Aktion 10.000 Zeilen.
In der Flow-Definition erscheint die Einstellung als paginationPolicy mit der Eigenschaft minimumItemCount. So sieht eine gefilterte, paginierte Abfrage im Code-Editor aus:
1{2 "Zeilen_auflisten": {3 "type": "OpenApiConnection",4 "inputs": {5 "host": {6 "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps",7 "connectionName": "shared_commondataserviceforapps",8 "operationId": "ListRecords"9 },10 "parameters": {11 "entityName": "accounts",12 "$select": "accountid,name,modifiedon",13 "$filter": "statecode eq 0",14 "$orderby": "accountid asc"15 }16 },17 "runtimeConfiguration": {18 "paginationPolicy": {19 "minimumItemCount": 10000020 }21 },22 "runAfter": {}23 }24}Das $orderby auf den Primärschlüssel ist kein Beiwerk. Ohne eindeutige Sortierung kann derselbe Datensatz laut Microsoft auf mehreren Seiten erscheinen.
Die Ursache liegt in der Listenansichtsschwelle von 5.000, nicht in Ihrer Filterabfrage. Die Aktion Elemente abrufen liefert laut Microsoft-Analyse zu Get items und Get files standardmäßig 100 Elemente und maximal 5.000 über Top Count.
Dokumentierte Nebenwirkung: Liegen in den ersten 5.000 Einträgen keine Treffer, kommt gar kein Ergebnis zurück, obwohl passende Datensätze existieren. Abhilfe schafft die Paginierung mit ausreichend hohem Schwellenwert. Power Automate ruft die Daten dann in Batches nach Top Count ab.
Leerzeichen in Spaltennamen schreiben Sie in der Filterabfrage als _x0020_. Die Null ist dabei die Ziffer, nicht der Buchstabe:
1Status eq 'Offen' and Start_x0020_Date ge '2026-01-01'Setzen Sie zusätzlich einen Index auf jede Spalte, die Sie filtern oder sortieren. Ohne Index läuft die Abfrage über die gesamte Liste und scheitert an der Schwelle.
Neben der Iterationszahl begrenzt Power Automate die Anzahl der Anfragen auf 100.000 Power-Platform-Anfragen je fünf Minuten. Dieser Wert gilt laut Grenzwertübersicht je Konto über alle Flows hinweg, nicht je Flow.
Mitgezählt wird jede Aktionsart, von der Variablen bis zum Connector-Aufruf. Auch fehlgeschlagene Aktionen, Wiederholungsversuche und die Anfragen der Paginierung zählen mit. Eine Schleife mit vier Aktionen erreicht die Grenze also nach 25.000 Durchläufen.
Microsoft empfiehlt in diesem Fall, die Last über mehrere Flows zu verteilen, etwa über untergeordnete Flows oder über Triggerbedingungen, die unnötige Läufe von vornherein verhindern.
Vier Muster halten Massenprozesse unter der Grenze, und sie greifen alle vor der Schleife, nicht darin.
Muster | Wirkung | Geeignet für
Muster: Früh filtern über $filter und $top · Wirkung: reduziert die Menge an der Quelle · Geeignet für: jede Abfrage mit bekannten Kriterien
Muster: Datumsfenster je Lauf · Wirkung: zerlegt den Bestand in Portionen · Geeignet für: Migrationen, Jahresabschlüsse
Muster: Array filtern und Auswählen statt Schleife · Wirkung: drei Aktionen statt Tausender · Geeignet für: reines Filtern und Umformen
Muster: Untergeordnete Flows · Wirkung: eigenes Aktionsbudget je Lauf · Geeignet für: Schleifen mit vielen Schritten je Element
Ein Datumsfenster bauen Sie mit den Ausdrücken aus dem Expression-Cookbook. Diese drei Zeilen liefern Start, Ende und Formatierung für einen Wochenlauf:
1formatDateTime(addDays(utcNow(), -7), 'yyyy-MM-ddTHH:mm:ssZ')2
3formatDateTime(utcNow(), 'yyyy-MM-ddTHH:mm:ssZ')4
5sub(length(body('Zeilen_auflisten')?['value']), 1)Prüfen Sie vor jedem Ausbau der Parallelität, ob die Reihenfolge zählt oder ob in der Schleife eine Variable beschrieben wird. Gleichzeitige Schreibzugriffe überholen sich sonst gegenseitig.
Vier Fehlerbilder treten rund um Schleifengrenzen und Paginierung regelmäßig auf.
Der Lauf bricht mit `WorkflowRunActionRepetitionQuotaExceeded` ab. Ursache: Die Schleife überschreitet ihre maximale Iterationszahl, weil die Quellaktion ungefiltert liefert. Lösung: $filter und $top in der Quellaktion setzen oder die Menge auf mehrere Läufe verteilen. Quelle: Fehlercodereferenz für Cloudflüsse.
Die Filterabfrage liefert keine Treffer, obwohl Datensätze passen. Ursache: Die Liste hat mehr als 5.000 Einträge und in den ersten 5.000 liegt kein Treffer. Lösung: Paginierung aktivieren und die Filterspalte indizieren. Quelle: Get items und Get files.
Die Antwort enthält keinen `@odata.nextLink` mehr. Ursache: Die Paginierung ist eingeschaltet und die Zeilenzahl überschreitet den konfigurierten Schwellenwert. Lösung: Paginierung ausschalten und das Skiptoken selbst auswerten, wenn Sie über 100.000 Zeilen hinausmüssen. Quelle: Zeilenlisten in Flows verwenden.
Ein SplitOn-Trigger verarbeitet nur 100 Elemente. Ursache: Am Trigger ist die Parallelität eingeschaltet, dadurch sinkt das SplitOn-Limit von 100.000 auf 100. Lösung: Trigger-Parallelität abschalten. Beachten Sie, dass sich das nur durch Löschen und Neuanlegen des Triggers rückgängig machen lässt. Quelle: Grenzwerte für automatisierte, geplante und Direktflows.
Die 100.000er-Grenze trifft Unternehmen meist erst beim Wachstum, etwa bei der Migration einer Altdatenbank oder beim Jahresreporting über alle Kundendatensätze. Für diese Fälle zahlt sich eine saubere Architektur aus gefilterten Quellabfragen, dimensionierter Paginierung und mehreren Läufen von Anfang an aus.
Wer seine Prozesse für große Datenmengen robust aufsetzen möchte, findet Unterstützung in der Power-Automate-Beratung von NordFlux. Die Grundlagen der Schleife selbst erklärt unsere Anleitung zu „Auf alle anwenden", und wie Sie die Schleife ganz vermeiden, zeigt der Beitrag zu Filter Array und Select.
Eine Apply-to-each-Schleife oder eine paginierte Aktion verarbeitet höchstens 100.000 Elemente je Flowausführung. Für mehr Daten empfiehlt Microsoft mehrere Läufe, gesteuert über ein Skiptoken, einen Datumsfilter oder einen Zeitplan-Trigger.
Nein. Sie gilt für die Profile „Mittel", „Hoch" und „Unlimited Extended". Im Profil „Niedrig", also bei kostenlosen Plänen, Microsoft-365-Plänen und Testlizenzen, liegt dieselbe Grenze bei 5.000 Elementen.
Die Apply-to-each-Grenze betrifft eine Schleife innerhalb eines Laufs. SplitOn betrifft Trigger, die ein Array in mehrere Workflowinstanzen zerlegen. Mit eingeschalteter Trigger-Parallelität sinkt das SplitOn-Limit auf 100 Elemente.
Der Lauf endet mit WorkflowRunActionRepetitionQuotaExceeded. Im Ausführungsverlauf steht der Fehler an der betroffenen Schleife. Unter Analysen auf der Flow-Details-Seite sehen Sie zusätzlich die verbrauchten Aktionen je Lauf.
Nein. Der maximal konfigurierbare Schwellenwert liegt bei 100.000. Durch die interne Aufrundung auf volle Seitengrößen kann die zurückgegebene Zeilenzahl über Ihrem Eintrag liegen, aber nicht über dieser Obergrenze.
Quellen: Microsoft Learn: Grenzwerte für automatisierte, geplante und Direktflows, Microsoft Learn: Fehlercodereferenz für Cloudflüsse, Microsoft Learn: Zeilenlisten in Flows verwenden, Microsoft Learn: Get items und Get files im Detail
Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.
Zertifizierungen
„Auf alle anwenden“ verarbeitet Listen Element für Element und entsteht oft ungewollt. Wie die Schleife funktioniert, warum sie bremst und wann sie weg kann.
Filter Array und Select ersetzen Apply to each beim Filtern und Umformen von Arrays und laufen deutlich schneller.
Excel-Tabelle, Apply to each, Outlook: So verschickt Power Automate an jede Zeile Ihrer Liste eine persönliche E-Mail.
Die Action-Burst-Grenze und die 100.000er-Iterationsgrenze treffen vor allem Prozesse mit wachsenden Datenmengen unerwartet hart. NordFlux baut Ihre Massenprozesse mit Paginierung und sauberer Fehlerbehandlung so, dass sie auch bei steigendem Volumen stabil bleiben.