Power Automate: 5 Fehler die jeden Flow irgendwann töten Power Automate: 5 Mistakes That Eventually Kill Every Flow
Diese Fehler sehe ich in jedem zweiten Kundenprojekt. Sie starten harmlos, wachsen still, und werden irgendwann zum echten Problem. I see these mistakes in every second client project. They start harmless, grow silently, and eventually become a real problem.
Power Automate ist einfach zu starten. Manchmal zu einfach. Denn was mit einem simplen Flow beginnt, wird in vielen Projekten zum unstrukturierten Wildwuchs, und irgendwann zum Problemherd.
Hier sind die fünf Fehler, die ich am häufigsten sehe. Alle lassen sich vermeiden, aber nur, wenn man sie kennt.
1. Keine Fehlerbehandlung, nirgendwo
Der häufigste Fehler: Flows ohne jegliche Fehlerbehandlung. Läuft alles durch, ist alles gut. Schlägt ein Schritt fehl, stirbt der Flow still, und niemand merkt es.
Was stattdessen funktioniert: Jeder kritische Block bekommt einen “Run After”-Zweig für Fehlerzustände, der mindestens eine Benachrichtigung auslöst. Für produktionskritische Flows: strukturiertes Logging in Dataverse oder SharePoint.
2. Variablen überall, Struktur nirgendwo
Flows wachsen. Zuerst eine Variable, dann drei, dann zehn, und irgendwann weiß niemand mehr, was varTemp2 eigentlich macht.
Was stattdessen funktioniert: Klare Benennungskonvention von Anfang an (strKundenname, intAnzahl, boolIstGenehmigt). Und: nicht alles in Variablen stecken, was sich auch direkt weiterverwenden lässt.
3. Trigger-Überladung
Ein Flow, der auf jede Änderung in einer SharePoint-Liste oder Dataverse-Tabelle reagiert, ohne Filter. Ergebnis: der Flow startet hundertmal täglich für Änderungen, die ihn gar nichts angehen.
Was stattdessen funktioniert: Trigger-Conditions nutzen. Für Dataverse: explizit definieren, welche Spaltenänderungen den Flow auslösen sollen.
4. Flows als Datenbankersatz
Power Automate ist ein Automatisierungswerkzeug, kein Speichermedium. Trotzdem sehe ich regelmäßig Flows, die riesige Datensätze in Arrays laden, durchsuchen und verarbeiten, weil “die Logik halt im Flow liegt”.
Was stattdessen funktioniert: Schwere Datenverarbeitung in Dataverse verlagern (gespeicherte Prozeduren, calculated columns, rollups) oder in Azure Functions auslagern. Der Flow orchestriert, er rechnet nicht.
5. Keine Versionskontrolle, kein ALM
„Ich teste im produktiven Tenant” ist kein Workflow, der funktioniert. Irgendwann kommt eine unbeabsichtigte Änderung, und der Rollback ist eine manuelle Tortur.
Was stattdessen funktioniert: Umgebungsstrategie (Dev / Test / Prod), Azure DevOps Pipelines für den Deployment-Prozess, und das Center of Excellence Starter Kit für Governance auf Tenantebene.
Diese fünf Punkte klingen grundlegend, und das sind sie. Aber genau deswegen werden sie so oft übersprungen. Nicht weil die Leute es nicht besser wissen. Sondern weil der erste Flow immer mit „nur kurz testen” beginnt.
Und dann bleibt er.
Power Automate is easy to get started with. Sometimes too easy. What begins with a simple flow often turns into unstructured chaos in many projects, and eventually becomes a source of problems.
Here are the five mistakes I see most often. All of them are avoidable, but only if you know them.
1. No Error Handling, Anywhere
The most common mistake: flows with no error handling at all. If everything succeeds, great. If a step fails, the flow dies silently, and no one notices.
What works instead: Every critical block gets a “Run After” branch for failure states, triggering at minimum a notification. For production-critical flows: structured logging in Dataverse or SharePoint.
2. Variables Everywhere, Structure Nowhere
Flows grow. First one variable, then three, then ten, and at some point nobody knows what varTemp2 actually does.
What works instead: A clear naming convention from the start (strCustomerName, intCount, boolIsApproved). And: don’t put everything into variables if it can be used directly downstream.
3. Trigger Overload
A flow that reacts to every change in a SharePoint list or Dataverse table, without filters. Result: the flow triggers hundreds of times a day for changes that are none of its business.
What works instead: Use trigger conditions. For Dataverse: explicitly define which column changes should trigger the flow.
4. Flows as Database Replacements
Power Automate is an automation tool, not a storage medium. Still, I regularly see flows that load massive datasets into arrays, search through them, and process them, because “the logic just lives in the flow.”
What works instead: Move heavy data processing to Dataverse (stored procedures, calculated columns, rollups) or offload to Azure Functions. The flow orchestrates, it doesn’t calculate.
5. No Version Control, No ALM
“I test in the production tenant” is not a workflow that works. Eventually an unintended change slips through, and the rollback is a manual nightmare.
What works instead: Environment strategy (Dev / Test / Prod), Azure DevOps Pipelines for the deployment process, and the Center of Excellence Starter Kit for governance at the tenant level.
These five points sound basic, and they are. But that’s exactly why they’re so often skipped. Not because people don’t know better. But because the first flow always starts with “just testing.”
And then it stays.