Fehlerbehandlung: Robustheit statt Trial & Error Error Handling: Robustness Instead of Trial and Error
Ein Flow, der still scheitert, ist gefährlicher als einer, der laut auf sich aufmerksam macht. Professionelle Fehlerbehandlung ist kein Bonus, sie ist Pflicht. What happens when a step fails? Robust automation doesn't stop working when something goes wrong, it handles it gracefully.
Fehlerbehandlung: Robustheit statt Trial & Error
Das Problem: Ein Flow läuft jeden Tag, und seit drei Wochen passiert nichts mehr. Niemand hat es gemerkt. Kein Alarm, keine Benachrichtigung, kein Log. Der Prozess ist still gestorben. Daten fehlen. Kunden warten. Chaos.
Die gefährlichsten Fehler sind die stillen
Fehler passieren. In jedem System, jedem Ablauf, jedem Prozess. Die Frage ist nicht: „Wie vermeide ich Fehler vollständig?”
Sondern: „Wie gehe ich mit ihnen um, wenn sie auftreten?”
Fehler, die unbemerkt bleiben, sind die gefährlichsten. Sie erzeugen Stillstand, Frust und Misstrauen in Automatisierungen.
In vielen Organisationen werden Prozesse so gebaut, als würden sie immer reibungslos ablaufen. Doch das tun sie nicht.
Die 3 Arten von Fehlern in Automatisierungen
graph TD
F["Fehlertypen"] --> T[" Technische Fehler"]
F --> L[" Logische Fehler"]
F --> A[" Anwenderfehler"]
T --> T1["API antwortet nicht"]
T --> T2["HTTP-Fehlercode 503"]
T --> T3["Ungültiges Datumsformat"]
L --> L1["Bedingung falsch formuliert"]
L --> L2["Else-Zweig fehlt"]
L --> L3["Flow endet zu früh"]
A --> A1["Pflichtfeld nicht ausgefüllt"]
A --> A2["Vorgang doppelt ausgelöst"]
A --> A3["Timeout durch Nutzer"]
style F fill:#fef3c7,stroke:#f59e0b
style T fill:#fee2e2,stroke:#ef4444
style L fill:#fce7f3,stroke:#ec4899
style A fill:#e0e7ff,stroke:#6366f1
Das Try-Catch-Finally-Muster für Power Automate
Professionelle Fehlerbehandlung folgt einem klassischen Muster aus der Softwareentwicklung:
┌──────────────────────────────────────────┐
│ [Scope: TRY] │
│ → Normaler Pfad: Was soll passieren? │
├──────────────────────────────────────────┤
│ [Scope: CATCH] │
│ → Was passiert, wenn etwas schiefgeht? │
│ → Fehler loggen, Benachrichtigung, │
│ Fallback einleiten │
├──────────────────────────────────────────┤
│ [Scope: FINALLY] │
│ → Was passiert immer? │
│ → Logging, Cleanup, Status setzen │
└──────────────────────────────────────────┘
In Power Automate umsetzbar mit drei Scope-Blöcken und „Configure Run After”.
Konkrete Praxisbeispiele
Beispiel 1: Eingabevalidierung
Problem: Ein Flow verarbeitet Formulardaten, aber das E-Mail-Feld ist leer.
Best Practice: Vor jeder Verarbeitung Pflichtfelder prüfen.
if(empty(triggerBody()?['email']), 'Fehler: E-Mail fehlt', triggerBody()?['email'])
Alternativ: Trigger Condition setzen, damit der Flow gar nicht erst startet, wenn Daten fehlen.
Beispiel 2: HTTP-Request schlägt fehl
Problem: Eine externe API antwortet mit Fehlercode 503.
Best Practice: Retry-Strategie + Fallback-Scope
In Power Automate kannst du für HTTP-Aktionen direkt konfigurieren:
- Anzahl der Wiederholungen: 0-90 Versuche
- Intervall: z. B.
PT20S= 20 Sekunden Wartezeit - Maximale Gesamtlaufzeit: begrenzen
Beispiel 3: Fehlerprotokoll statt Stille
Problem: Niemand weiß, dass der Flow seit drei Tagen fehlt.
Best Practice: Error Scope mit Notification + Log
Fehler tritt auf
↓
[CATCH Scope aktiviert]
↓
Teams-Benachrichtigung an Verantwortlichen
Eintrag in SharePoint-Fehlerliste
↓ (optional)
Manuelles Follow-up einleiten
Strukturiertes Logging: Was du immer erfassen solltest
| Feld | Beispiel |
|---|---|
Fehlercode | 400, 503, null |
Zeitstempel | 2024-04-13T09:12:00Z |
Flow-Name | HR_GenehmigeUrlaub_v2 |
Modul | Genehmigungslogik |
Status | Error |
Betroffene Daten | AntragID: 12345 |
Diese Daten in einer SharePoint-Liste oder Dataverse-Tabelle → darauf lässt sich mit Power BI ein Monitoring-Dashboard bauen.
Transparenz für Nutzer:innen
Fehler sind nicht nur ein technisches Problem, sie sind auch ein Kommunikationsproblem.
Wenn ein Nutzer nicht weiß, was passiert ist, entsteht Unsicherheit und Misstrauen.
| Maßnahme | Wirkung |
|---|---|
| Benachrichtigung bei Fehlern | Verantwortliche reagieren schnell |
| Protokolle | Nachvollziehbarkeit, Compliance |
| Fallback-Aktionen | z. B. manuelle Übergabe bei Auto-Fehler |
Der Grundsatz
“Fehler sind kein Zeichen von Schwäche, fehlende Reaktion darauf ist es.” sinngemäß nach Don Norman
Ein Flow, der bei einem Fehler still stirbt, ist gefährlicher als einer, der laut auf sich aufmerksam macht.
Fehlerbehandlung ist kein Bonus. Sie ist ein konzeptioneller Teil jeder ernsthaften Low-Code-Lösung.
Checkliste: Fehlerbehandlung in deinem nächsten Flow
- Pflichtfelder werden vor der Verarbeitung validiert
- Ein
Try-Scope enthält die Hauptlogik - Ein
Catch-Scope reagiert auf Fehler (Log + Benachrichtigung) - Ein
Finally-Scope setzt Status und räumt auf - Retry-Strategie ist für externe HTTP-Calls konfiguriert
- Fehler werden in einer zentralen Logliste protokolliert
- Zuständige Person wird bei Fehler automatisch informiert