Power Automate im Betrieb: Besitzer, Verbindungen, Fehler und Vertretung regeln

Ein produktiver Flow braucht Eigentümerschaft und Betrieb

Ein produktiver Power-Automate-Flow braucht mindestens eine fachlich verantwortliche Person und einen geregelten technischen Betrieb. Ein Flow ist ein automatisierter Ablauf, der durch ein Ereignis oder einen Zeitplan gestartet wird und anschliessend definierte Aktionen ausführt. Wenn nur die Person, die ihn erstellt hat, weiss, wie er funktioniert, ist der Ablauf noch nicht betriebsbereit.

Dafür braucht es Governance. Der Begriff bezeichnet verständliche Regeln für Zuständigkeiten, Zugriffe, Kontrolle und Änderungen. Diese Regeln müssen nicht umfangreich sein. Sie müssen aber beantworten, wer fachlich entscheidet, wem die verwendeten Verbindungen gehören, wie Fehler erkannt werden und wer bei Abwesenheit handeln kann.

Dieser Beitrag beschreibt ein praxistaugliches Zielmodell für KMU. Er stellt keinen verbindlichen oder bereits eingeführten BITS-Betriebsstandard dar. Welche technischen Identitäten, Überwachungsfunktionen und Richtlinien verfügbar sind, muss vor der Umsetzung anhand der jeweiligen Microsoft-365-Umgebung, der verwendeten Verbindungen und der aktuellen Lizenzbedingungen geprüft werden.

Der Go-live ist nicht das Ende des Projekts

Viele Automationen beginnen als persönliche Arbeitshilfe. Eine Fachperson baut beispielsweise einen Flow, der eine Formularantwort in eine Liste überträgt und danach eine Benachrichtigung verschickt. Das kann im kleinen Rahmen gut funktionieren.

Schwierig wird es, sobald sich andere Personen auf das Ergebnis verlassen. Die erstellende Person wechselt die Funktion, ein Kennwort läuft ab oder eine verwendete Datenquelle wird umbenannt. Der Prozess sieht weiterhin automatisiert aus, verarbeitet aber keine neuen Fälle mehr.

Bevor ein Flow produktiv eingesetzt wird, sollte er deshalb wie ein kleiner betrieblicher Prozess behandelt werden. Dazu gehören ein benannter Zweck, bekannte Abhängigkeiten, Testfälle, eine Fehlerreaktion und ein geregeltes Ende. Die technische Umsetzung ist nur ein Teil davon. Wie Sie vor der Umsetzung geeignete Abläufe auswählen, zeigt der Überblick zu Power-Automate-Prozessen für KMU.

Persönliche Konten, technische Identitäten und Verbindungen unterscheiden

Eine Verbindung speichert den Anmeldekontext, mit dem Power Automate auf einen Dienst wie SharePoint, Outlook oder eine Fachanwendung zugreift. Der Flow kann mehreren Personen gehören und trotzdem von einer Verbindung abhängen, die nur mit dem persönlichen Konto einer einzelnen Person funktioniert.

Für einen persönlichen Entwurf ist das oft ausreichend. Für einen geschäftskritischen Ablauf entsteht damit jedoch eine schwer sichtbare Abhängigkeit. Wird das Konto gesperrt, verliert Berechtigungen oder scheidet aus dem Unternehmen aus, kann die Automation unterbrochen werden. Eine zweite Person als Mitbesitzerin des Flows löst dieses Problem nicht automatisch, denn Besitz und Verbindung sind unterschiedliche Dinge.

Eine technische Identität ist ein Konto oder eine Anwendungsidentität, die für einen definierten technischen Zweck verwendet wird und nicht an die tägliche Arbeit einer einzelnen Person gebunden ist. Ob eine solche Identität eingesetzt werden kann und welche Form geeignet ist, hängt von der jeweiligen Verbindung und der Zielanwendung ab. Nicht jede Verbindung unterstützt dieselbe Vorgehensweise.

Halten Sie deshalb pro produktivem Flow fest:

• welche Konten und Verbindungen verwendet werden
• auf welche Daten diese zugreifen
• wer die Zugangsdaten und Berechtigungen verwaltet
• was bei einem Konto- oder Personalwechsel zu tun ist
• ob die gewählte Identität vom verwendeten Dienst unterstützt wird

Vier Rollen schaffen eine klare Zuständigkeit

In einem kleinen Unternehmen kann eine Person mehrere Rollen übernehmen. Die Rollen sollten trotzdem getrennt benannt werden, damit Entscheidungen nicht unbemerkt zwischen Fachbereich und IT liegen bleiben.

• Fachliche Eigentümerschaft: Entscheidet, wie der Prozess funktionieren muss, welche Ausnahmen zulässig sind und ob das Ergebnis fachlich korrekt ist.
• Technische Verantwortung: Pflegt den Flow, die Verbindungen und die technische Dokumentation und untersucht Fehler.
• Freigabe: Prüft vor produktiven Änderungen, ob Tests, Berechtigungen und Auswirkungen ausreichend berücksichtigt wurden.
• Vertretung: Kann bei Abwesenheit auf den Flow und seine Dokumentation zugreifen und die vereinbarten Massnahmen auslösen.

Für einfache Abläufe genügt möglicherweise eine kurze Zuordnung in einer zentralen Liste. Bei sensiblen Daten oder hohen Auswirkungen braucht es zusätzlich die verantwortliche Stelle für Datenschutz und Informationssicherheit.

Datenzugriffe und Umgebungen bewusst begrenzen

Eine Umgebung ist ein abgegrenzter Arbeitsbereich innerhalb der Power Platform, in dem Flows, Verbindungen und weitere Komponenten organisiert werden. Entwicklungs- und Produktivarbeit zu trennen, kann Änderungen kontrollierbarer machen. Die passende Struktur hängt jedoch von Grösse, Risiken und vorhandener Plattformverwaltung ab.

Ebenso wichtig sind Data-Loss-Prevention-Regeln, kurz DLP-Regeln. Sie legen fest, welche Datenverbindungen gemeinsam verwendet werden dürfen oder gesperrt werden sollen. Damit lässt sich beispielsweise verhindern, dass interne Geschäftsdaten unbeabsichtigt an einen nicht freigegebenen Dienst übertragen werden. Die konkrete Konfiguration muss zur Datenklassifikation und zu den tatsächlich eingesetzten Anwendungen passen.

Ein Flow sollte nur jene Berechtigungen erhalten, die sein Zweck verlangt. Ein automatisierter Ablageprozess benötigt nicht automatisch Zugriff auf sämtliche Websites oder Postfächer. Besonders schützenswerte Daten, komplexe externe Schnittstellen und rechtlich relevante Entscheide verlangen eine separate fachliche und sicherheitstechnische Prüfung.

Fehler müssen bei einer zuständigen Person ankommen

Die Ausführungshistorie zeigt, wann ein Flow gelaufen ist und ob einzelne Schritte erfolgreich waren. Sie ersetzt aber keine Überwachung. Ein technisch erfolgreicher Lauf kann fachlich trotzdem falsch sein, etwa wenn eine leere Datei abgelegt oder dieselbe Anfrage zweimal verarbeitet wurde.

Die folgenden Situationen sind Modellbeispiele, keine dokumentierten BITS-Projektergebnisse:

• Eine Verbindung verliert ihre Berechtigung und neue Anfragen bleiben unbearbeitet.
• Eine Spalte in einer Liste wird geändert, wodurch der Flow einen erwarteten Wert nicht mehr findet.
• Ein Sonderfall durchläuft den Flow technisch erfolgreich, wird aber der falschen Person zugewiesen.
• Eine automatische Wiederholung erzeugt ein zweites Dokument oder eine doppelte Nachricht.

Definieren Sie deshalb nicht nur, was als technischer Fehler gilt. Bestimmen Sie auch, bis wann ein Lauf abgeschlossen sein sollte, woran fehlende Ergebnisse erkannt werden und wer bei einer Abweichung informiert wird. Je nach Bedeutung können Plattformmeldungen, regelmässige Kontrollen oder eine separate technische Überwachung sinnvoll sein.

Der Fehlerweg sollte beschreiben, wer zuerst prüft, wie betroffene Personen informiert werden und wie nicht verarbeitete Fälle nachgeführt werden. Der Aufwand dafür gehört zu den Kosten einer Prozessautomatisierung, auch wenn er in einem ersten Prototyp kaum sichtbar ist.

Dokumentation, Änderungen und Ausserbetriebnahme regeln

Eine brauchbare Dokumentation muss keine technische Abhandlung sein. Sie sollte Zweck, Auslöser, wichtigste Schritte, Datenquellen, Verbindungen, Verantwortliche, bekannte Ausnahmen und den Fehlerweg enthalten. Zusätzlich braucht es eine verständliche Anweisung für die Vertretung.

Änderungen sollten zuerst mit realistischen Testfällen geprüft werden. Dazu gehören Standardfälle, fehlende Angaben, doppelte Eingaben und jene Ausnahmen, die im Arbeitsalltag tatsächlich vorkommen. Nach der Freigabe wird dokumentiert, was geändert wurde und wer die fachliche Wirkung geprüft hat.

Auch das Ende gehört zum Lebenszyklus. Wird ein Flow ersetzt, müssen Zeitpläne deaktiviert, nicht mehr benötigte Verbindungen und Berechtigungen entfernt sowie offene Fälle kontrolliert werden. Einfaches Löschen kann Abhängigkeiten oder unbearbeitete Vorgänge verdecken.

Checkliste für den ersten produktiven Flow

Vor dem Go-live sollten Sie diese Fragen mit Ja beantworten können:

• Ist der fachliche Zweck in wenigen Sätzen dokumentiert?
• Sind fachliche Verantwortung, technische Betreuung und Vertretung benannt?
• Sind Konten, Verbindungen und benötigte Berechtigungen bekannt?
• Wurden Normalfälle und wichtige Ausnahmen getestet?
• Erreichen Fehler eine Person, die reagieren kann?
• Ist beschrieben, wie fehlgeschlagene Fälle nachgeführt werden?
• Gibt es einen geregelten Weg für Änderungen und Ausserbetriebnahme?

Power Automate passt nicht zu jedem Prozess. Unklare Regeln, häufig wechselnde Ausnahmen oder ein nicht beherrschbares Schadenspotenzial sprechen gegen eine vorschnelle Automation. In solchen Situationen sollte zuerst der Ablauf vereinfacht oder eine dafür ausgelegte Fachanwendung geprüft werden.

Wenn Sie einen konkreten Ablauf beurteilen möchten, bietet die Seite zu Prozessen und Automation einen passenden Ausgangspunkt. Entscheidend ist nicht die Anzahl der Flows, sondern ob der gewählte Ablauf auch bei Änderungen, Fehlern und Abwesenheiten verständlich betrieben werden kann.

Microsoft-Quellen und Prüfstand

Die technischen Grundlagen wurden am 14. September 2026 mit Microsoft Learn geprüft. Microsoft beschreibt dort die Verwaltung von Verbindungen in Power Automate, den Wechsel und die Verantwortung von Flow-Besitzenden, Power-Platform-Umgebungen und ihre Trennung sowie Datenrichtlinien für Connectors und Umgebungen. Verfügbare Identitäten, Richtlinien, Überwachungsfunktionen und Lizenzvoraussetzungen müssen für den jeweiligen Mandanten und die eingesetzten Connectors vor der Umsetzung erneut bestätigt werden.