Performance-Tuning für Power-Automate-Flows

Ein Power-Automate-Flow, der minutenlang für eine Aufgabe braucht, die eigentlich in Sekunden erledigt sein könnte, kostet nicht nur Zeit. Er verbraucht unnötig viele der begrenzten Aktionsanforderungen deines Plans, treibt Timeout-Fehler in nachgelagerten Systemen hoch und macht die Fehlersuche schwerer, weil bei jedem Lauf mehr Schritte durchlaufen werden müssen. Die gute Nachricht: Die meisten Performance-Probleme in Power Automate lassen sich auf drei Hebel zurückführen, die Microsoft in den eigenen Coding Guidelines ausführlich dokumentiert. Stand: Juli 2026.

Dieser Beitrag fasst zusammen, wie du mit gezielter Parallelität, einer Reduktion unnötiger Aktionen und der richtigen Connector- beziehungsweise Datenwahl spürbar schnellere Flows baust, basierend auf der offiziellen Microsoft-Dokumentation zu Power Automate. Du behältst dabei die Kontrolle darüber, welcher Hebel für deinen konkreten Flow den größten Effekt bringt, statt wahllos an Stellschrauben zu drehen, die kaum etwas verändern.

Warum Flows überhaupt langsam werden

Bevor du optimierst, lohnt sich ein Blick auf die Ursache. Laut der Anleitung zur Diagnose von Leistungsproblemen erreichen viele verlangsamte Flows schlicht ihre täglichen Power-Automate-Limits. Über die Aktionsanalyse in „Meine Flows" siehst du, wie viele Aktionsanforderungen ein Flow tatsächlich verbraucht, und Power Automate benachrichtigt Besitzer sogar per E-Mail, wenn ein Flow wiederholt gegen Aktionslimits läuft. Genauso wichtig: Auch die verbundenen Dienste selbst setzen Schutzgrenzwerte, die sich in deinem Flow als Fehler 429 (zu viele Anfragen) oder 5xx (Timeout) zeigen. Diese Grenzwerte unterscheiden sich je nach Connector und Dienst, weshalb dieselbe Flow-Logik bei SharePoint ganz anders performen kann als bei Dataverse oder einer externen API.

Hebel 1: Parallelität gezielt einsetzen

Parallelzweige für unabhängige Schritte

Laut der Anleitung zur parallelen Ausführung und Parallelität lohnen sich Parallelzweige immer dann, wenn zwei oder mehr Aktionen nicht voneinander abhängen und einzeln länger als fünf Sekunden dauern. Typische Anwendungsfälle sind laut Microsoft nicht blockierende Genehmigungsanfragen, quorumsbasierte Genehmigungsprozesse, das gleichzeitige Erstellen oder Aktualisieren von Datensätzen in mehreren Systemen sowie das parallele Initialisieren mehrerer Variablen.

Concurrency Control in Für-alle-übernehmen-Schleifen

Noch deutlicher wird der Effekt in Schleifen. Standardmäßig arbeitet eine Für-alle-übernehmen-Schleife sequenziell, Element für Element. Die Dokumentation zeigt an einem Testarray mit vier Einträgen, wie stark sich das durch Parallelität verkürzt:

• Parallelität deaktiviert: 21 Sekunden
• Grad der Parallelität 2: 11 Sekunden
• Grad der Parallelität 4: 6 Sekunden
• Grad der Parallelität 6: 6 Sekunden

Du kannst den Grad der Parallelität zwischen 1 und 50 setzen. Wichtig dabei: Eine hohe Zahl macht nicht automatisch alles schneller, weil das Aufteilen der Arbeit, das Einreihen zusätzlicher Threads und Verzögerungen durch den aufgerufenen Endpunkt selbst Mehraufwand erzeugen. Verschachtelte Für-alle-übernehmen-Schleifen laufen zudem immer sequenziell, die Parallelitätssteuerung wirkt laut Microsoft nur auf der obersten Ebene des Cloud-Flows.

Trigger-Parallelität nur mit Bedacht

Auf Trigger-Ebene lässt sich zusätzlich eine Parallelitätssteuerung aktivieren, die festlegt, wie viele Instanzen eines Flows gleichzeitig laufen dürfen, standardmäßig ist sie ausgeschaltet. Sie hilft bei Datenquellen mit begrenztem Durchsatz und verhindert sogenannte Dirty Reads, bei denen ein Flow mit veralteten Daten weiterarbeitet, weil eine parallele Ausführung den Datensatz zwischenzeitlich geändert hat. Microsoft rät jedoch ausdrücklich zur Vorsicht: Die Einstellung lässt sich nach dem Aktivieren nicht mehr rückgängig machen, sondern nur durch das Neuanlegen des Triggers. Als bewährte Methode empfiehlt die Dokumentation, Parallelitätssteuerung nur auf einen dedizierten untergeordneten Flow mit möglichst wenigen Aktionen anzuwenden, statt den gesamten Hauptflow zu betreffen.

Hebel 2: Unnötige Aktionen und Schleifen reduzieren

Verschachtelte Schleifen vermeiden

Der Leitfaden zu Anti-Mustern in Cloud-Flows nennt verschachtelte Für-alle-übernehmen-Schleifen als eine der teuersten Fallen. Zwei Schleifen mit je zehn Iterationen ergeben rechnerisch 100 Durchläufe, bei größeren Datenmengen wächst diese Zahl exponentiell und stößt schnell an die Grenzwerte für Iterationen und Gesamtausführungszeit. Die dokumentierte Alternative: OData-Abfrageerweiterung nutzen, um verknüpfte Datensätze in einer einzigen Abfrage mitzuladen, statt sie in einer zweiten, inneren Schleife nachzuladen. Ein Parameter wie `Products($select=ProductName,Price)` ersetzt dabei die komplette innere Schleife durch einen einzigen zusätzlichen RetrieveMultiple-Aufruf an Dataverse.

Trigger-Bedingungen statt nachgelagerter Prüfungen

Viele Flows starten bei jeder Änderung einer Datenquelle, obwohl nur ein Bruchteil der Ausführungen tatsächlich relevant ist. Eine Triggerbedingung, die direkt am Trigger geprüft wird, verhindert diese überflüssigen Läufe von vornherein, statt sie erst nach dem Start des Flows über eine interne Bedingung abzufangen. Das spart nicht nur Zeit, sondern auch Aktionsanforderungen, die sonst für jeden irrelevanten Lauf verbraucht würden.

Batch- und Massenvorgänge statt Einzelaktionen

Wer hunderte oder tausende Datensätze anlegen oder aktualisieren muss, sollte laut Dokumentation nicht jeden Datensatz einzeln in einer For-each-Schleife verarbeiten. Batchvorgänge fassen mehrere Anfragen in einer einzigen HTTP-Anforderung zusammen, während Massenvorgangs-Web-APIs in Dataverse noch einen Schritt weitergehen: Statt vieler einzelner „Zeile erstellen"-Aktionen zählt ein Aufruf der CreateMultiple-Web-API mit 100 vorbereiteten Datensätzen nur als eine einzige Aktion.

Hebel 3: Connector-Wahl und Datenmenge begrenzen

Nur die Daten laden, die du wirklich brauchst

Laut dem Leitfaden Arbeiten Sie nur mit relevanten Daten lässt sich die verarbeitete Datenmenge sowohl am Trigger als auch an einzelnen Aktionen begrenzen. Bei Dataverse-Quellen reduzieren die Parameter Spalten auswählen, Zeilen filtern und Zeilenanzahl die Ergebnismenge direkt an der Quelle. Bei SharePoint erfüllen Filterabfrage, Höchstzahl und Spalten nach Ansicht einschränken denselben Zweck. Das ist relevant, weil sogenannte Durchsatzgrenzwerte begrenzen, wie viel Datenvolumen ein Cloud-Flow innerhalb eines Zeitraums aus seinem Ausführungsverlauf lesen und schreiben darf. Wird dieser Grenzwert dauerhaft über 14 Tage überschritten, schaltet Power Automate den Flow automatisch ab.

Die richtige Aktion statt der bequemsten

Connector-Wahl bedeutet auch, für dieselbe Aufgabe nicht automatisch zur aufwendigsten Aktion zu greifen. Datenoperationen wie Filter array, Select oder Join verarbeiten Arrays direkt und reduzieren die Datenmenge, die durch nachfolgende Schritte läuft, oft deutlich effizienter als eine zusätzliche Schleife mit Bedingungen. Wo ein Dienst native Filter- oder Selektionsparameter im Connector selbst anbietet, ist es laut Microsoft-Dokumentation effizienter, dort zu filtern, statt die komplette Datenmenge erst in den Flow zu laden und anschließend mit einer separaten Datenoperation zu reduzieren.

So findest du den Flaschenhals in deinem eigenen Flow

Am schnellsten findest du die tatsächliche Ursache mit einer festen Prüfreihenfolge. Öffne zunächst die Aktionsanalyse des betroffenen Flows und sieh nach, ob er nahe an seinen täglichen Limits läuft. Prüfe danach den Ausführungsverlauf auf einzelne Aktionen mit auffällig langer Laufzeit, meist sind es Schleifen ohne Parallelität oder Aktionen, die unnötig große Datenmengen laden. Kontrolliere außerdem, ob Fehler vom Typ 429 oder 5xx auftauchen, die auf Grenzwerte eines verbundenen Diensts hindeuten und nicht auf Power Automate selbst. Bei umfangreicheren Flow-Landschaften mit mehreren Umgebungen lohnt sich oft eine strukturierte Power-Automate-Beratung, die Parallelität, Datenvolumen und Connector-Wahl einmal systematisch für alle kritischen Flows durchgeht, statt jeden Flow einzeln zu optimieren.

Häufige Fragen

Wie viele Elemente sollte ich parallel in einer Für-alle-übernehmen-Schleife verarbeiten?

Es gibt keinen pauschalen Bestwert, Microsoft erlaubt einen Grad der Parallelität zwischen 1 und 50. In der dokumentierten Beispielmessung mit vier Elementen brachte bereits eine Parallelität von 4 die maximale Beschleunigung, eine weitere Erhöhung auf 6 änderte nichts mehr an der Laufzeit. In der Praxis lohnt es sich, mit einem moderaten Wert wie 5 bis 10 zu starten und die Laufzeit im Ausführungsverlauf zu beobachten, statt direkt den Maximalwert zu setzen, weil zu hohe Parallelität selbst Verzögerungen durch den aufgerufenen Endpunkt erzeugen kann.

Verbessert Trigger-Parallelitätssteuerung automatisch die Performance?

Nicht automatisch, und Microsoft rät sogar zur Zurückhaltung. Die Standardeinstellung ohne Parallelitätssteuerung lässt so viele gleichzeitige Läufe zu, wie das System verarbeiten kann, was für die meisten Szenarien bereits ausreichend performant ist. Parallelitätssteuerung ist vor allem dann sinnvoll, wenn eine angebundene Ressource nur begrenzten Durchsatz verträgt oder Dirty Reads verhindert werden müssen, nicht als generelle Beschleunigungsmaßnahme. Da sich die Einstellung nicht rückgängig machen lässt, solltest du sie nur gezielt auf einen kleinen, dedizierten Flow anwenden.

Warum sind verschachtelte Schleifen ein so großes Performance-Problem?

Weil sich die Anzahl der Durchläufe multipliziert statt addiert. Zwei ineinander verschachtelte Schleifen mit je zehn Elementen führen zu 100 Einzeldurchläufen, bei größeren Datenmengen steigt diese Zahl exponentiell weiter an. Das kostet nicht nur Zeit, sondern nähert den Flow schnell an die Grenzwerte für Iterationen und Gesamtausführungszeit an, was im schlimmsten Fall zu Flowfehlern oder Drosselung führt.

Was hat die Wahl des Connectors mit Performance zu tun, wenn mehrere Connectors dieselbe Aufgabe können?

Häufig bieten Connectors unterschiedlich granulare Filter- und Selektionsparameter direkt an der Datenquelle an. Ein Connector, der Filterung, Spaltenauswahl und eine maximale Zeilenzahl bereits am Trigger oder an der Aktion unterstützt, reduziert die verarbeitete Datenmenge, bevor sie überhaupt im Flow ankommt. Das wirkt sich direkt auf die Durchsatzgrenzwerte aus und verringert das Risiko, dass ein Flow wegen zu hohen Datenvolumens gedrosselt oder nach anhaltender Überschreitung sogar automatisch abgeschaltet wird.

Wie erkenne ich, ob ein langsamer Flow an Power Automate oder am verbundenen Dienst liegt?

Ein Blick auf die Fehlercodes im Ausführungsverlauf gibt die Antwort. Fehler vom Typ 429 oder Timeouts im 5xx-Bereich deuten auf Schutzgrenzwerte des verbundenen Diensts hin, die je nach Connector unterschiedlich ausfallen. Erreicht dagegen Power Automate selbst seine täglichen Aktionsanforderungen, zeigt die Aktionsanalyse in „Meine Flows" das deutlich an, und Besitzer erhalten zusätzlich eine automatische Benachrichtigung mit Hinweisen zur Reduzierung der Aktionsanzahl.