Minimal-Dokumentation für Power-Automate-Flows: Wissen sichern statt an eine Person binden

Wenn ein Flow ausfällt und die einzige Person, die seine Logik kennt, gerade im Urlaub ist oder das Unternehmen bereits verlassen hat, wird aus einem kleinen Fehler schnell ein Betriebsrisiko. Power Automate macht es leicht, in wenigen Minuten einen funktionierenden Flow zu bauen, aber genauso leicht vergisst man dabei, warum eine Aktion so und nicht anders konfiguriert wurde. Ein Minimal-Dokumentationsstandard schließt genau diese Lücke, ohne dass Du für jeden Flow ein aufwendiges Handbuch schreiben musst.

Die Idee dahinter ist einfach: Wenige, konsequent gepflegte Angaben reichen aus, damit ein fremder Kollege oder eine Kollegin einen Flow innerhalb weniger Minuten versteht, statt ihn Schritt für Schritt zu rekonstruieren. Dieser Artikel zeigt, welche Elemente ein solcher Minimal-Standard braucht und wie Du ihn mit Bordmitteln von Power Automate umsetzt.

Warum ein Minimal-Standard reicht

Vollständige Dokumentation für jeden Flow ist in der Praxis kaum durchzuhalten. Wer versucht, jede Aktion bis ins letzte Detail zu beschreiben, hört nach wenigen Wochen wieder auf, weil der Aufwand zu groß wird. Ein Minimal-Standard setzt bewusst niedrig an: Er verlangt nur die Angaben, die im Ernstfall wirklich gebraucht werden, wenn jemand anderes den Flow übernehmen oder reparieren muss. Genau dieses Prinzip, wenige verbindliche Regeln statt eines umfassenden Regelwerks, empfehlen auch die Coding Guidelines für Cloud Flows von Microsoft: konsistente Namen, eine kurze Beschreibung und punktuelle Kommentare an den Stellen, an denen die Logik nicht selbsterklärend ist.

Die Flow-Beschreibung als Startpunkt

Jeder Flow hat ein Beschreibungsfeld, das beim Erstellen oder nachträglich in den Details ausgefüllt werden kann. In der Praxis bleibt dieses Feld oft leer, dabei ist es der erste Ort, an dem jemand nach dem Zweck eines Flows sucht. Für den Minimal-Standard reichen drei bis vier Sätze:

• Zweck: Welches Geschäftsproblem der Flow in einem Satz löst.
• Auslöser und Ergebnis: Was den Flow startet und was am Ende passiert.
• Beteiligte Systeme: Welche Connectoren oder externen Dienste im Spiel sind, etwa SharePoint, Outlook oder eine Business-Line-Anwendung.
• Ansprechperson oder Team: Wer bei Rückfragen kontaktiert werden kann, idealerweise ein Team-Postfach statt eine einzelne Person.

Diese vier Punkte lassen sich in unter fünf Minuten pro Flow ausfüllen und sparen später Stunden an Reverse Engineering.

Namenskonventionen, die jeder versteht

Trigger und Aktionen heißen standardmäßig oft wie die ausgeführte Funktion, etwa „Eine E-Mail senden“, ohne erkennen zu lassen, warum diese Aktion im Flow steht. Laut den Richtlinien zur konsistenten Benennung von Flowkomponenten gehören dazu folgende Regeln:

• Beschreibende Namen statt Standardbezeichnungen: Aus „Trigger1“ wird „Neue E-Mail empfangen“, aus „Bedingung“ wird „Prüfen ob Rechnung über 1000 Euro“.
• CamelCase oder Unterstriche: Wörter werden lesbar getrennt, etwa „sendEmailNotification“ statt einem zusammengeschriebenen Namen.
• Präfixe zur Kategorisierung: Kürzel wie „Trg_“ für Trigger, „Act_“ für Aktionen oder „Var_“ für Variablen zeigen auf einen Blick, um welche Komponente es sich handelt.
• Einheitliche Anwendung über alle Flows hinweg: Eine einmal festgelegte Konvention gilt für das gesamte Team, nicht nur für einzelne Flows.
• Schriftliche Festlegung der Konvention: Die Regeln selbst gehören in einen Styleguide, sonst driftet die Benennung nach ein paar Monaten wieder auseinander.

Wer diese Regeln konsequent anwendet, kann einen fremden Flow allein an den Aktionsnamen grob nachvollziehen, ganz ohne jede Aktion zu öffnen.

Notizen an den Stellen, die Erklärung brauchen

Nicht jede Aktion braucht eine Notiz, aber jede Aktion mit einer nicht offensichtlichen Logik sollte eine bekommen. Power Automate bietet dafür eine eigene Funktion direkt im Designer. Laut der Anleitung zum Hinzufügen von Notizen wählst Du dazu die Auslassungspunkte neben einer Aktion und dann Notiz hinzufügen aus, im neuen Designer über das vertikale Menü an der jeweiligen Aktion. Die Notiz erscheint danach direkt unter dem Aktionsnamen und ist beim Öffnen des Flows sofort sichtbar, ohne dass jemand extra danach suchen muss.

Für den Minimal-Standard reicht es, Notizen an drei Stellen zu setzen:

• Bei Verzweigungen oder Bedingungen, deren Kriterium nicht aus dem Namen hervorgeht.
• Bei Workarounds, etwa wenn eine Aktion aus einem bestimmten Grund anders konfiguriert wurde, als naheliegend wäre.
• Bei Schleifen oder wiederholten Blöcken, damit klar ist, worüber iteriert wird und warum.

So bleibt der Aufwand überschaubar, während genau die Stellen erklärt sind, an denen sich sonst jemand am längsten festbeißt.

Ein zentraler Ort für alle Standards

Ein Minimal-Standard nützt wenig, wenn ihn nur eine Person kennt. Microsoft empfiehlt in der Anleitung zum Aufbau von Community-Tools für die Power Platform eine zentrale SharePoint-Kommunikationswebsite, auf der Namenskonventionen, Richtlinien und Verantwortlichkeiten für alle Ersteller einsehbar sind. Für ein kleineres Team reicht auch eine einzelne Seite in einem bestehenden Wiki oder Teams-Kanal, solange sie an einem festen, bekannten Ort liegt. Wichtig ist vor allem, dass dort die Namenskonventionen, die Verantwortlichkeiten der Flow-Ersteller und der Weg zum Support dokumentiert sind, nicht nur einmalig verschickt, sondern dauerhaft auffindbar.

Minimal-Standard als Checkliste

Damit der Standard nicht nur eine Idee bleibt, hilft eine feste Checkliste, die vor jeder Veröffentlichung eines Flows durchgegangen wird:

• Beschreibungsfeld ausgefüllt mit Zweck, Auslöser, Systemen und Ansprechperson.
• Trigger, Aktionen und Variablen nach der vereinbarten Namenskonvention benannt.
• Notizen an Bedingungen, Workarounds und Schleifen gesetzt.
• Mindestens ein Miteigentümer eingetragen, damit der Flow nicht an einer einzelnen Person hängt.
• Fundort der Standards im internen Wiki oder auf der Kommunikationswebsite bekannt und verlinkt.

Fünf Punkte, die sich in wenigen Minuten abhaken lassen, aber im Ernstfall den Unterschied zwischen einem reparierbaren und einem verlorenen Flow ausmachen. Wer diesen Standard einmal im Team verankert, behält die Kontrolle über seine digitalen Mitarbeiter, auch wenn sich die Besetzung ändert. NordFlux unterstützt Dich dabei mit Power-Automate-Beratung zum Festpreis, von der Namenskonvention bis zur laufenden Wartung.

Häufige Fragen

Wie viel Zeit kostet der Minimal-Standard pro Flow wirklich?

Für die Flow-Beschreibung, ein paar sprechende Namen und zwei bis drei Notizen an den kritischen Stellen solltest Du fünf bis zehn Minuten einplanen, je nach Komplexität des Flows. Das ist deutlich weniger Zeit, als später gebraucht wird, um einen unbekannten Flow ohne jede Erklärung zu verstehen.

Wo genau trage ich die Flow-Beschreibung ein?

Das Beschreibungsfeld findest Du beim Erstellen eines Flows sowie nachträglich in den Flow-Details. Es ist ein einfaches Textfeld, das mit dem Flow gespeichert wird und für alle Besitzer und Miteigentümer sichtbar ist, unabhängig davon, wer den Flow zuletzt bearbeitet hat.

Was gehört in eine Notiz und was eher in die Flow-Beschreibung?

Die Flow-Beschreibung erklärt den Flow als Ganzes: Zweck, Auslöser, beteiligte Systeme. Eine Notiz erklärt dagegen eine einzelne Aktion oder Bedingung im Detail, etwa warum ein bestimmter Schwellenwert oder eine bestimmte Filterbedingung gewählt wurde. Wer beides vermischt, macht die Beschreibung unübersichtlich und die Notizen redundant.

Muss ich bestehende Flows nachträglich dokumentieren?

Idealerweise ja, zumindest für geschäftskritische Flows. Ein praktikabler Weg ist, den Minimal-Standard zunächst für alle neuen Flows verbindlich zu machen und bestehende Flows nach und nach nachzuziehen, etwa immer dann, wenn ohnehin eine Änderung ansteht.

Reicht es, wenn nur eine Person im Team die Namenskonventionen kennt?

Nein, genau das würde den Sinn des Minimal-Standards untergraben. Die Konventionen gehören schriftlich fixiert an einem zentralen, für alle Ersteller zugänglichen Ort, etwa einer SharePoint-Kommunikationswebsite oder einem internen Wiki, damit neue Teammitglieder sie ohne Rückfrage finden.