Power Automate Throttling und Action-Limits: Wann Ihre Flows gedrosselt werden

Power Automate drosselt Flows, sobald sie eines von mehreren Limits überschreiten. Das wichtigste ist das Action-Burst-Limit von 100.000 Aktionen in fünf Minuten, das unabhängig von der Lizenz gilt. Hinzu kommen tägliche Grenzen an Power-Platform-Requests je nach Lizenz und Beschränkungen für gleichzeitige Läufe. Wer diese Grenzen kennt, baut Flows, die auch unter Last verlässlich durchlaufen, statt bei einem großen Datensatz plötzlich stehenzubleiben.

Dieser Beitrag ergänzt unseren Überblick zur Effizienzsteigerung mit Power-Automate-Workflows in Dynamics 365 um die Frage, wo die technischen Grenzen liegen und wie Sie darunter bleiben.

Was Throttling ist und wann es zuschlägt

Throttling bedeutet, dass die Plattform Ihre Aufrufe verlangsamt oder zurückweist, sobald ein Grenzwert erreicht ist. Das ist kein Fehler in Ihrem Flow, sondern ein Schutzmechanismus, der die Servicequalität für alle Kunden sichert. Technisch äußert sich Throttling als Antwort mit dem Fehlercode 429 (Too Many Requests) und einem Hinweistext wie „Rate limit is exceeded. Try again in 27 seconds".

Die Zahl im Retry-After-Header ist entscheidend. Sie nennt die Wartezeit in Sekunden, nach der ein neuer Versuch erlaubt ist. Power Automate wiederholt gedrosselte Aufrufe automatisch nach dieser Wartezeit. Der Haken: jeder Wiederholungsversuch zählt erneut als Aktion und verbraucht damit weiteres Kontingent. Ein Flow, der gegen ein Limit läuft und immer wieder neu versucht, verstärkt sein eigenes Problem.

Bleibt es nicht bei einer kurzen Bremse, wird es ernst. Wird ein Flow 14 Tage in Folge durchgehend gedrosselt, schaltet die Plattform ihn ab. Sie können ihn wieder aktivieren, doch solange er die Limits weiter verletzt, deaktiviert Power Automate ihn erneut. Throttling ist also kein reines Performance-Thema, sondern eine Frage der Betriebssicherheit.

Die wichtigsten Limits im Überblick

Drei Arten von Grenzen wirken zusammen. Die folgende Tabelle fasst die zentralen Werte zusammen, die Microsoft in seiner Dokumentation zu den Limits automatisierter, geplanter und sofortiger Flows nennt.

Action-Burst und tägliche Requests unterscheiden

Diese beiden Limits werden oft verwechselt, greifen aber getrennt. Das tägliche Request-Limit ist Ihr Gesamtbudget über 24 Stunden hinweg, verteilt auf alle Läufe aller Ihrer Flows, im Detail aufgeschlüsselt in Microsoft Learn zu den Request-Limits und Kontingenten. Das Action-Burst-Limit begrenzt zusätzlich die Geschwindigkeit. Ein Flow mit Process-Lizenz darf zwar 250.000 Requests am Tag machen, aber nie mehr als 100.000 davon innerhalb von fünf Minuten. Wer 200.000 Aktionen in kurzer Zeit durch eine Schleife jagt, läuft in den Burst-Deckel, obwohl das Tagesbudget noch reicht.

Wichtig ist auch, was überhaupt zählt. Als Aktion gilt jeder Trigger, jede Konnektor-Aktion, jede HTTP-Aktion und selbst eingebaute Aktionen wie das Initialisieren einer Variable oder ein einfaches Compose. Erfolgreiche wie fehlgeschlagene Aktionen zählen, nur übersprungene nicht. Ein Apply-to-each über 5.000 Datensätze mit drei Aktionen pro Durchlauf erzeugt allein 15.000 Requests in einem einzigen Lauf.

Concurrency und Pagination

Neben den reinen Mengenlimits steuert Power Automate, wie viel gleichzeitig passiert. Ist die Concurrency Control am Trigger aktiv, laufen zwischen 1 und 100 Instanzen parallel, standardmäßig 25. Innerhalb einer Schleife steuert die Parallelität des Apply-to-each, wie viele Iterationen zugleich arbeiten, Standard ist 1 und maximal 50. Genau diese Parallelität ist ein zweischneidiges Schwert: Sie beschleunigt den Flow, kann aber die Aufrufe so verdichten, dass Konnektoren mit 429 antworten.

Typische Ursachen für Throttling

In der Praxis lassen sich fast alle Drosselungen auf wenige Muster zurückführen.

• Schleifen mit vielen Aktionen: Ein Apply-to-each über tausende Datensätze mit mehreren Aktionen pro Durchlauf multipliziert den Request-Verbrauch. Fünf Aktionen über 20.000 Elemente sind bereits 100.000 Requests in einem Lauf und stoßen direkt an den Burst-Deckel.
• Zu häufig auslösende Trigger: Ein Trigger, der bei jeder E-Mail oder jeder Datensatzänderung feuert, startet den Flow weit öfter als gedacht. Selbst ein schlanker Flow erreicht so das Tageslimit, wenn er nur oft genug läuft.
• Ungedrosseltes paralleles Apply-to-each: Wird die Parallelität hochgesetzt, um Zeit zu sparen, treffen viele gleichzeitige Aufrufe auf denselben Konnektor. SharePoint, Dataverse und externe APIs quittieren das mit 429.
• Wiederholungen, die sich aufschaukeln: Jeder Retry auf eine gedrosselte Aktion ist selbst wieder eine Aktion. Ein Flow, der bereits am Limit ist, verschärft seine Lage mit jedem automatischen Neuversuch.

Ein verwandtes Muster entsteht, wenn Flows nicht sauber mit fehlenden Werten umgehen und deshalb unnötige Zweige und Aktionen durchlaufen. Wie Sie das schlank halten, zeigt unser Beitrag zum Umgang mit Null-Werten in Power Automate.

So vermeiden Sie Throttling

Die gute Nachricht: Fast jede Ursache lässt sich mit sauberem Design abstellen. Der rote Faden lautet, so wenige Aktionen wie möglich pro Lauf zu erzeugen und die verbleibenden zeitlich zu entzerren.

An der Quelle filtern statt im Flow

Der wirksamste Hebel ist, gar nicht erst zu viele Daten in den Flow zu holen. Nutzen Sie Filterabfragen (OData) direkt in der Konnektor-Aktion, statt alle Datensätze zu laden und danach in einer Schleife zu prüfen. Was die Quelle bereits ausschließt, verbraucht keine Aktion. Ein „Get items" mit sauberem Filter und einer sinnvollen Top-Angabe schlägt jedes nachgelagerte Condition-Konstrukt.

Batching statt Einzelaufrufe

Wo eine API Sammelvorgänge unterstützt, verarbeiten Sie mehrere Datensätze in einem Aufruf statt einzeln in der Schleife. Für Dataverse bieten sich Batch-Operationen an, für andere Systeme oft eine einzige HTTP-Aktion mit einem Array im Body. So sinkt die Zahl der Requests deutlich, ohne dass Sie an Funktionalität verlieren.

Concurrency bewusst steuern

Setzen Sie die Parallelität eines Apply-to-each nicht reflexartig hoch. Ein moderater Wert entzerrt die Aufrufe und hält Sie unter den Konnektor-Limits. Trifft Ihr Flow trotzdem auf 429, hilft eine bewusst niedrigere Parallelität oft mehr als jede Erhöhung. Bei sehr großen Mengen ist es sinnvoll, die Arbeit über mehrere Läufe zu verteilen und pro Lauf nur einen Teil zu verarbeiten, statt alles in einen einzigen Durchlauf zu zwängen.

Pagination und Datenmengen im Griff behalten

Pagination hilft, große Ergebnismengen zu laden, aber jede zusätzliche Seite zählt als Aktion. Begrenzen Sie das Schwellenwert-Limit auf das, was Sie wirklich brauchen. Ein Apply-to-each verarbeitet je nach Performance-Profil bis zu 100.000 Elemente, doch das ist ein Deckel, keine Empfehlung. Fällt regelmäßig mehr an, teilen Sie den Bestand auf mehrere zeitlich versetzte Läufe auf.

Aktionen reduzieren und Logik verlagern

Jede eingesparte Aktion senkt den Verbrauch. Fassen Sie mehrere Compose- und Variablen-Schritte zusammen und prüfen Sie, ob eine Aufgabe besser an anderer Stelle aufgehoben ist. Manche Validierung gehört nicht in einen Flow, sondern serverseitig in ein Plugin. Welches Werkzeug wofür das richtige ist, klärt unser Leitfaden zu Business Rule, JavaScript, Plugin oder Cloud Flow.

Lizenz und Service-Prinzipale prüfen

Ist ein Flow wirklich dauerhaft am Limit, ist ein Upgrade der ehrliche Weg. Eine Process-Lizenz reserviert 250.000 Requests für genau diesen Flow, unabhängig vom Besitzer, und mehrere Process-Lizenzen lassen sich auf demselben Flow stapeln, wenn er in einer Lösung liegt. Ein Capacity-Add-on erhöht die Grenze um jeweils 50.000 Requests pro Tag. Für reine Hintergrundprozesse ohne Nutzerinteraktion lohnt der Blick auf Service-Prinzipale und Anwendungsbenutzer, deren Verbrauch aus dem nicht-lizenzierten Request-Pool des Tenants stammt.

Verlässliche Quellen und nächster Schritt

Die konkreten Zahlen ändern sich gelegentlich und viele Organisationen befinden sich derzeit in einer Übergangsphase mit großzügigeren Werten. Bauen Sie Ihre Flows dennoch gegen die offiziellen Limits. Verbindliche Details liefert Microsoft Learn zum Thema Plattform-Limits und Throttling vermeiden.

Wenn Ihre Flows unter Last drosseln oder ganze Prozesse an Stoßzeiten scheitern, prüfen wir Design, Lizenzierung und Datenmengen gemeinsam und bauen eine tragfähige Architektur. Sprechen Sie uns an.