Personenabhängigkeit bei Power Automate vermeiden — Flows am Laufen halten, nachdem ihr Ersteller das Unternehmen verlässt

„Wir hatten eine Mitarbeiterin, die sich mit Power Automate gut auskannte, und sie hat allerlei Prozesse im ganzen Unternehmen automatisiert. Jetzt geht sie nächsten Monat, und niemand weiß, was die Flows eigentlich tun.“ Solche Beratungsanfragen haben in letzter Zeit spürbar zugenommen. Manchmal kommen sie sogar noch später an – die Person ist bereits gegangen, und „die Bestellbenachrichtigungs-E-Mails kommen seit letztem Monat nicht mehr an, und niemand kann das reparieren.“

In einem früheren Artikel, „Ein System ohne Quellcode und ohne Dokumentation übernehmen ── ein praktisches Vorgehen, um es am Laufen zu halten“, haben wir die Übernahme eines Systems behandelt, dessen Ersteller nicht mehr da ist. Power-Automate-Flows neigen, wenn überhaupt, eher noch stärker zu genau dieser Situation, gerade weil sie ohne Code gebaut werden können – und anders als eine ausführbare Datei bringen sie keine Garantie mit, einfach „weiter zu existieren“. Flows sind eng an das Konto und die Verbindungen ihres Erstellers gebunden, und die Art, wie sie kaputtgehen, ändert sich in dem Moment, in dem dieses Konto deaktiviert oder gelöscht wird. Dieser Artikel prüft anhand der offiziellen Microsoft-Dokumentation, was tatsächlich mit einem Flow passiert, wenn sein Besitzer verschwindet, und legt dann dar, was vor dem Ausscheiden zu tun ist, was sich danach noch tun lässt, und wie Bestandsaufnahme und Design des Ausführungskontos aussehen müssen, damit Personenabhängigkeit erst gar nicht entsteht – in der Reihenfolge, in der ein kleines oder mittleres Unternehmen das tatsächlich durcharbeiten würde.

1. Die wichtigsten Punkte vorab

• Der Ersteller wird zum Besitzer eines Flows, und die zur Ausführung genutzten Verbindungen (die Authentifizierung gegenüber SharePoint, Outlook und Ähnlichem) sind an das Konto der Person gebunden, die sie erstellt hat. Eine gemeinsam genutzte Verbindung lässt sich nur innerhalb dieses Flows verwenden, und nicht einmal ein Mitbesitzer kann die Anmeldedaten einer von jemand anderem erstellten Verbindung ändern.¹
• Auch nachdem der Besitzer ausgeschieden ist, läuft der Flow selbst weiter, solange ein Mitbesitzer bestehen bleibt. Aktionen, die die Verbindungen der ausgeschiedenen Person nutzen, beginnen jedoch zu scheitern, sodass die Verbindungen ausgetauscht werden müssen.¹²
• Ein Flow ganz ohne gültigen Besitzer wird zu einem „verwaisten Flow“. Administratoren finden solche Flows auf der Umgebungsseite des Power Platform Admin Centers (Ressourcen → Flows) und können über Freigeben einen neuen Besitzer hinzufügen. Auch eine massenhafte Bearbeitung mit PowerShell (Get-AdminFlow, Set-AdminFlowOwnerRole) ist möglich.²
• Arbeiten Sie vor dem Ausscheiden in zwei Schritten: „Mitbesitzer hinzufügen“ und „den Besitzer wechseln“. Die Neuzuweisung des Besitzers (eine Übergabe, während die Person noch angestellt ist) ist nur bei lösungsbewussten Flows möglich; Flows außerhalb einer Lösung müssen erst einer Lösung hinzugefügt oder per Export/Import neu aufgebaut werden.³⁴
• Das Problem, dass Benachrichtigungs-E-Mails weiterhin unter dem Namen einer Einzelperson verschickt werden, lässt sich vermeiden, indem der Versand auf ein gemeinsames Postfach verlagert wird (die Aktion „E-Mail über ein freigegebenes Postfach senden (V2)“), das von einem Ausscheiden unberührt bleibt. Auch Microsofts eigene Anleitung empfiehlt für Routinebenachrichtigungen einen gemeinsamen Absender statt eines individuellen Namens.⁵⁶
• Dienstkonten auf Basis gemeinsam genutzter Benutzerkonten werden als Best Practice nicht empfohlen, und ein Dienstprinzipal als Besitzer ist die offizielle Empfehlung für geschäftskritische Flows. Da es für kleinere Unternehmen Einrichtungs- und Lizenzierungshürden gibt, legt Kapitel 5 dieses Artikels einen realistischen Entscheidungsweg dar.⁴⁷⁸
• Der erste Schritt ist nicht technischer Natur – er besteht in der Bestandsaufnahme. Beginnen Sie damit, mithilfe des Admin Centers und Get-AdminFlow aufzulisten, welche Flows im gesamten Unternehmen existieren, und bauen Sie ein minimales Flow-Register auf (Name, Zweck, Besitzer, Verbindungen, betroffene Prozesse).⁹

2. Wie Flows zur Domäne einer einzelnen Person werden

Personenabhängigkeit bei Power Automate entsteht nicht aus Böswilligkeit oder Nachlässigkeit, sondern aus einer Anhäufung guter Absichten. Der typische Verlauf sieht so aus.

1. Jemand, der sich vor Ort auskennt, baut einen Flow, um die eigene Arbeit zu erleichtern. Etwas Kleines, in der Art von „Forms-Antworten in Excel kopieren“.
2. Es ist nützlich, also steigen Kollegen mit ein. „Schick mir diese Benachrichtigung auch für meine Abteilung.“ „Könnte er auch die Bestellungen speichern?“ Anfragen häufen sich, Flows vervielfachen und wachsen.
3. Bevor es jemand bemerkt, hat er sich im Kernbetrieb festgesetzt. Bestellbenachrichtigungen an vorderster Front, Rechnungsablage, Weiterleitung von Genehmigungen – Prozesse, bei denen „der Betrieb stockt, wenn er stoppt“ – laufen am Ende auf Flows im individuellen Konto genau dieser einen Person.
4. Er läuft stabil, ohne dass jemand weiß, was darin steckt. Es gibt keinen Grund, etwas anzufassen, das funktioniert, also entstehen weder Übergabe noch Dokumentation. „Wir können es nicht anfassen, weil es funktioniert“ wird direkt zu „niemand kann es anfassen“.

Bis hierhin gleicht das Bild dem eines Entwicklers, der geht, und eines Systems, das ohne Quellcode und ohne Spezifikation zurückbleibt. Aber Power Automate hat zwei Aspekte, die noch unangenehmer sind als bei einem Legacy-System. Erstens: Der Ort, an dem Flows gebaut werden, ist „Meine Flows“ einer Person – niemand außer ihr kann überhaupt sehen, dass sie existieren. Anders als bei einem System mit einer ausführbaren Datei auf einem Server taucht ein Flow nicht einmal in einer Liste auf, bis man aktiv eine Bestandsaufnahme macht. Zweitens: Die Ausführung eines Flows hängt vom Konto und den Verbindungen seines Erstellers ab. In dem Moment, in dem der Offboarding-Prozess das Konto deaktiviert oder löscht, tritt die Auswirkung zutage. Der nächste Abschnitt prüft genau, wie sich das verhält.

3. Was mit einem Flow passiert, wenn das Konto verschwindet

Der Flow selbst wird nicht gelöscht, wird aber zu einem „verwaisten Flow“

Zunächst zu den Grundlagen: Das Löschen des Kontos einer ausgeschiedenen Person aus Microsoft Entra ID löscht die von ihr gebauten Flows nicht automatisch. Flows und Verbindungen zählen zu den Dingen, die „ein Administrator prüft und manuell löscht“, sie verschwinden also nicht von selbst – aber der Ausführungsverlauf wird beim Löschen des Kontos automatisch gelöscht. Wenn Sie sich bisher auf vergangene Ausführungsprotokolle als Nachweis verlassen haben, sollten Sie das beachten.¹⁰

Selbst wenn der Flow überlebt, gerät ein Flow ohne gültigen Besitzer in einen Zustand, der als verwaister Flow bekannt ist. Microsofts Supportdokumentation definiert einen verwaisten Flow als „einen Flow ohne gültigen Besitzer“ und hält ausdrücklich fest, dass ein Flow fehlschlagen kann, wenn er Verbindungen nutzt, die an das Konto eines aus der Organisation ausgeschiedenen Benutzers gebunden sind.²

Verbindungen sind an das Konto dieser Person gebunden

Das ist der eigentliche Druckpunkt. Die von jeder Aktion in einem Flow genutzten Verbindungen (Authentifizierung gegenüber SharePoint, Outlook, Teams und Ähnlichem) laufen unter den Anmeldedaten des Benutzers, der sie erstellt hat. Die offizielle FAQ für den Fall, dass der Ersteller eines gemeinsam genutzten Flows das Unternehmen verlässt, hält Folgendes fest.¹

• Bleibt ein gültiger Besitzer wie ein Mitbesitzer bestehen, läuft der Flow selbst weiter
• Allerdings können Aktionen, die Verbindungen im Namen der ausgeschiedenen Person nutzen, fehlschlagen, sodass die Anmeldedaten der Verbindung aktualisiert werden müssen (in der Praxis: die Verbindung jeder Aktion im Flow-Designer auf eine Verbindung eines anderen Kontos umstellen)

Zudem lässt sich eine gemeinsam genutzte Verbindung nur innerhalb dieses einen Flows verwenden, und selbst ein Mitbesitzer kann die Anmeldedaten einer von einem anderen Besitzer erstellten Verbindung nicht ändern.¹ Mit anderen Worten: „Wir sind auf der sicheren Seite, weil wir Mitbesitzer hinzugefügt haben“ ist nur halb richtig – die Übergabe ist erst abgeschlossen, wenn Sie die Verbindungen der ausgeschiedenen Person tatsächlich aus dem Flow entfernt haben (jede Aktion auf die eigene Verbindung umstellen und speichern).

Lizenzierungsfolgen ── die 14-Tage-Abschaltung

Flows, die Premium-Connectoren und Ähnliches nutzen, laufen unter der Lizenz ihres Besitzers. Laut der offiziellen Lizenz-FAQ wird ein Premium-Flow, dessen Lizenzgrundlage weggefallen ist – etwa weil der Besitzer ausgeschieden ist – auf einen Zustand mit gedrosselter Leistung herabgestuft, alle Besitzer werden benachrichtigt, und der Flow wird nach 14 Tagen abgeschaltet, wenn nichts unternommen wird.⁴ Das ist ein zeitgesteuertes Verhalten: „Irgendwie ist er langsamer geworden“, und zwei Wochen später stoppt er. Flows, die nur Standard-Connectoren nutzen, sind davon weniger betroffen, aber welche Ihrer Flows Premium-Funktionen nutzen, ist genau die Information, die Sie durch eine Bestandsaufnahme ermitteln sollten (die Grenze zwischen Standard und Premium wird in „Power-Automate-Lizenzierung und die Grenze zwischen Standard- und Premium-Connectoren“ dargelegt).

E-Mails werden weiterhin unter dem Namen dieser Person verschickt

Etwas, das leicht übersehen wird, ist der „Name“ auf Benachrichtigungen. Die Aktion „E-Mail senden (V2)“ versendet aus dem Postfach des verbundenen Benutzers, sodass, solange der Flow weiterläuft, Benachrichtigungs-E-Mails weiterhin unter dem persönlichen Namen des Erstellers verschickt werden. Solange die Person noch angestellt ist, ist das lediglich eine Kuriosität nach dem Motto „warum bekomme ich jeden Morgen eine E-Mail von dieser Person?“; nach ihrem Ausscheiden schlägt der Versand selbst fehl, da das Konto deaktiviert ist. Tauscht ein Mitbesitzer umgekehrt einfach die Verbindung gegen die eigene aus, gehen alle Benachrichtigungen fortan unter dessen Namen hinaus.

Microsofts Anleitung empfiehlt, routinemäßige geschäftliche Benachrichtigungen nicht unter dem Namen einer Einzelperson zu versenden, sondern stattdessen einen gemeinsamen Absender zu verwenden. Bei Outlook erlaubt die Aktion „E-Mail über ein freigegebenes Postfach senden (V2)“ den Versand aus einem gemeinsamen Postfach (zum Beispiel noreply-flow@example.co.jp), und der Versandverlauf bleibt im Ordner „Gesendete Elemente“ des gemeinsamen Postfachs erhalten (der Versand erfordert eine Berechtigung auf dem Postfach). Für Teams-Benachrichtigungen übernimmt die Aktionsfamilie „Als Flow-Bot posten“ dieselbe Rolle. Eine Signatur in der Art „Diese E-Mail wird automatisch von Power Automate versendet; Rückfragen bitte an X“ hinzuzufügen sorgt zudem dafür, dass Empfänger nicht im Unklaren bleiben, wenn sich die zuständige Person ändert.⁵⁶

4. Was vor dem Ausscheiden zu tun ist, und was sich danach noch tun lässt

Vor dem Ausscheiden ── zwei Wochen reichen

Sobald ein Ausscheiden oder ein Wechsel feststeht, arbeiten Sie Folgendes der Reihe nach ab.

flowchart TD
    Start[Ausscheiden oder Wechsel steht fest] --> Inventory[Meine Flows der Person auflisten<br/>die geschäftlich genutzten identifizieren]
    Inventory --> Coowner[Nachfolger und IT als Mitbesitzer hinzufügen]
    Coowner --> Solution{Ist es ein<br/>lösungsbewusster Flow?}
    Solution -- Ja --> Owner[Besitzer über die Detailseite wechseln]
    Solution -- Nein --> AddSol[Einer Lösung hinzufügen und Besitzer wechseln<br/>oder per Export/Import neu aufbauen]
    Owner --> Conn[Verbindung jeder Aktion<br/>auf eine Verbindung des neuen Kontos umstellen]
    AddSol --> Conn
    Conn --> Mail[Benachrichtigungsabsender auf ein gemeinsames Postfach o. Ä. verlagern]
    Mail --> Test[Per Testlauf bestätigen, dass es auch<br/>bei deaktiviertem Konto der ausgeschiedenen Person funktioniert]

1. Die Flows der Person auflisten. Öffnen Sie gemeinsam mit ihr den Bildschirm „Meine Flows“ und sortieren Sie die Einträge in „geschäftlich genutzt“, „persönliche Effizienz“ und „Überbleibsel aus Experimenten“. Es ist effizient, gleich hier die erste Fassung des Flow-Registers aus Kapitel 6 zu erstellen.
2. Mitbesitzer hinzufügen. Fügen Sie den Nachfolger und den IT-Ansprechpartner (oder ersatzweise jemanden mit Administratorrechten) als Besitzer des Flows hinzu. Mitbesitzer können den Ausführungsverlauf einsehen, bearbeiten, stoppen, den Flow löschen und Besitzer hinzufügen.¹ Beachten Sie, dass das Hinzufügen von Mitbesitzern nur eine minimale Notlösung ist; die offizielle Empfehlung lautet, die alltägliche Freigabe wo immer möglich auf reine Ausführungsrechte zu beschränken.⁷
3. Den Besitzer neu zuweisen. Bei einem lösungsbewussten Flow können Sie den Besitzer über die Detailseite des Flows auf den Nachfolger (oder ein Dienstkonto) ändern. Nach dem Wechsel werden sowohl der ursprüngliche als auch der neue Besitzer zu Mitbesitzern, und geplante sowie automatisierte Flows beginnen, unter der Lizenz des neuen Besitzers zu laufen (das kann bis zu 7 Tage dauern, bis es wirksam wird; Öffnen und Speichern des Flows wendet es sofort an).³ Bei Flows außerhalb einer Lösung ist der Besitzer Teil der Identität des Flows, sodass der Besitzer nicht direkt geändert werden kann. Ist Dataverse in der Umgebung verfügbar, fügen Sie den Flow zunächst einer Lösung hinzu und ändern ihn dann; andernfalls bauen Sie ihn per Export/Import oder „Speichern unter“ unter dem neuen Besitzer neu auf.³⁴
4. Die Verbindungen austauschen. Wie im vorherigen Abschnitt beschrieben, bleibt die Übergabe unvollständig, wenn Sie diesen Schritt überspringen. Stellen Sie im Flow-Designer die Verbindung jeder Aktion auf eine Verbindung des neuen Kontos um und speichern Sie. Entfernen Sie die ausgeschiedene Person aus den Besitzern, müssen auch die Anmeldedaten der von ihr genutzten Verbindungen aktualisiert werden.¹
5. Testen. Führen Sie, wenn möglich, einen vollständigen Durchlauf bei deaktiviertem Konto der ausgeschiedenen Person durch (oder in einem Zeitraum wie dem Jahresurlaub, in dem sie nichts bedient), und bestätigen Sie, dass es unter denselben Bedingungen funktioniert, die nach ihrem Weggang gelten werden.

Nach dem Ausscheiden ── was ein Administrator tun kann

Selbst wenn die Person bereits gegangen ist und es keinen Besitzer gibt, bleiben Handlungsmöglichkeiten.

• Die verwaisten Flows im Admin Center finden. Wählen Sie im Power Platform Admin Center die Umgebung aus und öffnen Sie Ressourcen → Flows, um die Liste der Flows in dieser Umgebung zu sehen. Flows mit leerer Spalte „Besitzer“ sind die verwaisten.²
• Über Freigeben einen neuen Besitzer hinzufügen. Wählen Sie den Flow in der Liste aus, fügen Sie über Freigeben das Konto des neuen Besitzers hinzu und speichern Sie.² Beachten Sie: Möchte ein Administrator den Inhalt eines Flows ändern, ist auch dort die Voraussetzung, sich selbst als Besitzer oder Mitbesitzer hinzuzufügen.³
• Bei vielen Flows massenhaft mit PowerShell bearbeiten. Mit dem Verwaltungsmodul (Microsoft.PowerApps.Administration.PowerShell) listet Get-AdminFlow -CreatedBy <Objekt-ID der ausgeschiedenen Person> die von ihr erstellten Flows auf, und Set-AdminFlowOwnerRole -RoleName CanEdit gewährt Mitbesitz. Aktuelle Berechtigungen prüfen Sie mit Get-AdminFlowOwnerRole.²
• Die Verbindungen neu erstellen. Nach der Übernahme des Besitzes stellen Sie Verbindungen im Namen der ausgeschiedenen Person auf Verbindungen des neuen Kontos um. Ist das Konto der ausgeschiedenen Person bereits gelöscht, lassen sich die ursprünglichen Verbindungen nicht wiederherstellen – Sie erstellen dann neue Verbindungen und weisen sie jeder Aktion neu zu.¹

Als Randnotiz: Genehmigungs-Flows haben ihre eigene, eigentümliche Art hängenzubleiben – „noch offene Genehmigungsanfragen, die weiterhin der ausgeschiedenen Person zugewiesen sind“. Die Neuzuweisung auf Genehmigerseite und das Eskalationsdesign werden in den Kapiteln 5 und 6 von „Einen Genehmigungs-Workflow in Power Automate erstellen“ behandelt; bitte ziehen Sie diesen Artikel zurate.

5. Das Ausführungskonto gestalten ── Einzelperson, Dienstkonto oder Dienstprinzipal

Um die Übergabehektik nicht immer wieder zu wiederholen, besteht die grundlegende Lösung darin, im Voraus festzulegen, „unter wessen Namen geschäftliche Flows laufen“. Hier ein Vergleich der Optionen.

Hier eine praktische Faustregel für die Wahl.

• Werkzeuge für die persönliche Effizienz können auf Einzelkonten bleiben. Der Versuch, alles streng zu verwalten, dämpft genau die Automatisierung, die vor Ort entsteht.
• Geschäftliche Flows, von denen eine Abteilung abhängt, sollten mindestens ihren Benachrichtigungsabsender auf ein gemeinsames Postfach verlagern⁵ und zwei oder mehr Mitbesitzer haben. Richten Sie ein Dienstkonto zur Ausführung ein, beschränken Sie dessen Berechtigungen auf das notwendige Minimum und den Zugriff auf die Anmeldedaten auf eine Handvoll Personen. Microsoft selbst rät eher zu einem Dienstprinzipal als zu einem Dienstkonto,⁴ doch im kleineren Maßstab, konzentriert auf Standard-Connectoren, ist „ein dediziertes Konto plus konsequente Kennwortverwaltung“ oft die realistische Antwort.
• Flows, die an unternehmensweite Kernprozesse gebunden sind (alles, was direkt mit Bestellungen, Rechnungsstellung oder Zahlungen verbunden ist), lohnt es sich, für einen Dienstprinzipal als Besitzer in Betracht zu ziehen. Da der Besitzer keine Person mehr ist, bleibt er von Ausscheiden unberührt, und Sie vermeiden den Unfall, dass ein Flow stoppt, weil dem Besitzer die Lizenz entzogen wurde.⁸ Es gibt jedoch Einschränkungen – ein Dienstprinzipal kann kein Mitbesitzer sein (er kann nur als Besitzer verwendet werden), und Premium-Funktionen erfordern eine Process-Lizenz –, sodass dies ab diesem Punkt eine Stufe ist, die gemeinsam mit Ihrer IT-Abteilung oder einem externen Spezialisten gestaltet werden sollte.⁸

Noch etwas: Selbst wenn Sie ein Dienstkonto einrichten, sollten Sie nicht die gesamte Flow-Erstellung und kleinere Bearbeitungen unter diesem Namen vornehmen. Wenn die Person, die baut, unter ihrem eigenen Konto baut, und nur Besitz und Ausführung beim Dienstkonto liegen, behalten Sie die Nachvollziehbarkeit von „wer hat wann was geändert“.

6. Bestandsaufnahme und Dokumentation ── zuerst wissen, was existiert

Der Ausgangspunkt, um Personenabhängigkeit entgegenzuwirken, ist, dass die Organisation versteht, welche Flows unternehmensweit existieren. Genauso wie der erste Schritt bei der Übernahme eines Blackbox-Systems eine Bestandsaufnahme der ausführbaren Dateien und geplanten Aufgaben ist, haben Flows ihr eigenes standardmäßiges Vorgehen zur Bestandsaufnahme.

Eine Liste der Flows erhalten

• Über das Admin Center: Öffnen Sie auf der Umgebungsseite des Power Platform Admin Centers Ressourcen → Flows, und Sie erhalten eine Liste der Flows dieser Umgebung samt ihrer Besitzer. Hier finden Sie auch die verwaisten Flows.²
• Über PowerShell: Das Verwaltungs-Cmdlet Get-AdminFlow liefert alle Flows in den von Ihnen verwalteten Umgebungen, wenn Sie Umgebungsadministrator sind, oder alle Flows im gesamten Mandanten, wenn Sie globaler Administrator sind. Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv' liefert Ihnen sofort den Grundstock eines CSV-Registers, und Get-AdminFlowWithHttpAction grenzt auf genau die Flows ein, die HTTP-Aktionen nutzen (diejenigen, bei denen am wahrscheinlichsten eine Integration mit etwas Externem vorliegt).⁹ Wenn Sie sich mit PowerShell noch nicht wohlfühlen, lohnt sich auch ein Blick in „PowerShell-Befehlsgrundlagen ── Was Sie zuerst lernen sollten und wie Sie es sicher einsetzen“.

Ein minimales Flow-Register

Das Register schlicht zu halten, ist der Trick, um es dauerhaft zu pflegen. In einer SharePoint-Liste oder in Excel eine Zeile pro Flow, mit nur diesen Spalten.

Die entscheidende Spalte ist „auf wessen Namen jede Verbindung lautet“. Besitzer lassen sich vom Admin-Bildschirm ablesen, aber der Name auf einer Verbindung lässt sich nur durch Öffnen des Flows ermitteln, was ihn zur wertvollsten Information macht, die im Register schriftlich festgehalten werden sollte.

Namenskonventionen und das Beschreibungsfeld

Microsofts Richtlinien für sauberen Code empfehlen, Flow-Komponenten aussagekräftige, konsistente Namen zu geben, Namenskonventionen zu dokumentieren und zu teilen sowie Notizen an Aktionen anzuhängen, die denselben Zweck erfüllen wie Code-Kommentare.¹¹ In der Praxis macht es einen enormen Unterschied für die Lesbarkeit der Liste, Flow-Namen einfach nach dem Schema „[Abteilung] Prozessname – Was er tut“ zu vereinheitlichen (zum Beispiel „[Vertrieb] FAX-Bestellungen – PDF speichern und Besitzer benachrichtigen“). Die Detailseite eines Flows verfügt zudem über ein Beschreibungsfeld, für das Copilot einen Entwurf erzeugen kann,¹² sodass es sich als Absicherung für den Tag, an dem das Register veraltet, auszahlt, denselben Inhalt wie den „Zweck“ des Registers auch in den Flow selbst zu schreiben.

Sobald Sie ein Register haben, rückt die nächste Frage in den Blick: Wer bemerkt es, wenn ein Flow mit einem Fehler stoppt? Fehlerbenachrichtigung und Wiederholungsdesign werden ausführlich in „Fehlerbehandlung und Wiederholungsdesign in Power Automate“ behandelt.

7. Umgebungen und Lösungen ── über „alles in der Standardumgebung“ hinausgehen

Power Platform verfügt über ein Partitionierungskonzept namens Umgebung, und jeder Flow, der ohne Angabe einer solchen gebaut wird, landet in der Standardumgebung. Die Standardumgebung ist für jeden Benutzer im Mandanten zugänglich, und jeder Mitarbeiter mit einer Microsoft-365-Lizenz kann dort Apps und Flows bauen. Als Sandkasten für persönliche Produktivität ist das in Ordnung, aber Microsofts eigene Anleitung weist darauf hin, dass sich in der Standardumgebung tendenziell besitzerlose Ressourcen ansammeln, wenn Ersteller das Unternehmen verlassen, und dass Flows, die weit verbreitet oder geschäftskritisch geworden sind, in eine dedizierte Umgebung verschoben werden sollten.¹³

Ein kleines oder mittleres Unternehmen muss nicht sofort zu einer vollständigen Umgebungstrennung (Entwicklung, Test, Produktion) übergehen. Zwei Dinge sind aber auch im kleinen Maßstab wert, im Blick zu behalten.

• Flows, die in den Kernbetrieb vorgedrungen sind, in eine Lösung packen. Eine Lösung ist ein Container, der einen Flow und seine Komponenten gemeinsam transportiert, und ein Flow innerhalb einer solchen (ein lösungsbewusster Flow) kann seinen Besitzer direkt geändert bekommen, seine Verbindungen als leicht austauschbare „Verbindungsreferenzen“ halten und erhält einen Versionsverlauf.³¹⁴ Wie Kapitel 4 gezeigt hat, macht dies die Übergabe bei Ausscheiden ungleich leichter. Die Nutzung von Lösungen erfordert eine Umgebung mit Dataverse.¹⁴
• Ihre DLP-Richtlinien mindestens einmal überprüfen. Richtlinien zur Verhinderung von Datenverlust (DLP), die Connectoren als geschäftlich oder nicht geschäftlich klassifizieren und die Kombinationen einschränken, sind das Sicherheitsnetz gegen einen entgleisten Flow, der interne Daten an einen externen Dienst weitergibt.¹⁵ Die übergreifenden Überlegungen zur Governance werden in Kapitel 9 von „Geschäftsprozesse mit Power Automate automatisieren“ angesprochen.

Umgebungstrennung, ALM (eine Pipeline Entwicklung → Test → Produktion) und unternehmensweite Steuerung über das CoE Starter Kit liegen alle noch weiter auf diesem Weg, lohnen sich aber erst, sobald Ihre Flow-Zahl im zweistelligen Bereich liegt. Zuerst Register und Lösungen, dann Umgebungen.

8. Entscheidungstabelle ── wessen Vermögenswert ist dieser Flow?

Zum Schluss, wie sich die Grenze ziehen lässt, auf welcher Ebene jeder einzelne Flow verwaltet werden sollte. Jeden Flow streng zu verwalten ist unrealistisch, teilen Sie sie daher nach „wer beeinträchtigt ist, wenn er stoppt“ in drei Stufen ein.

Wie Sie an einen Flow herangehen, der in der untersten Zeile gelandet ist, entspricht der Übernahme eines Systems ohne Quellcode und ohne Dokumentation, die am Anfang dieses Artikels erwähnt wurde. Statt ihn sofort neu aufzubauen, beginnen Sie damit, den Trigger, die Verbindungen und die Ausgabeziele zu beobachten und „was er tut“ ins Register zu schreiben. Zum Glück zeigt Ihnen ein Flow, anders als eine EXE ohne Quellcode, alles im Inneren. Solange Sie Mitbesitzer werden können, ist das Entziffern der Definition selbst nicht schwierig.

Es stellt sich auch die Frage, „sollte diese Verarbeitung überhaupt in Power Automate bleiben?“ Komplexe Flows, ein fruchtbarer Boden für Personenabhängigkeit, lassen sich manchmal leichter übergeben, wenn sie in PowerShell-Skripte, die Aufgabenplanung oder eine Funktion des Fachsystems selbst verlagert werden, da sich diese unter Git-Verwaltung und Code-Review stellen lassen. Diese Entscheidung wird in „Die Wahl zwischen Power Automate und PowerShell + Aufgabenplanung“ dargelegt.

9. Zusammenfassung

• Ein Flow ist an das Konto und die Verbindungen seines Erstellers gebunden. Verschwindet ein Konto beim Ausscheiden, bleibt der Flow selbst bestehen, aber der Ausführungsverlauf wird automatisch gelöscht, Aktionen mit Verbindungen im Namen der ausgeschiedenen Person schlagen fehl, und Premium-Flows werden nach einer Karenzzeit von 14 Tagen abgeschaltet.¹⁰²⁴
• Vor dem Ausscheiden reichen zwei Wochen für eine Übergabe in dieser Reihenfolge: Mitbesitzer hinzufügen → Besitzer wechseln (falls lösungsbewusst) → Verbindungen austauschen → Absendernamen auf ein gemeinsames Postfach verlagern.³¹
• Auch nachdem die Person gegangen ist, lassen sich verwaiste Flows über Ressourcen → Flows im Admin Center oder per PowerShell (Get-AdminFlow/Set-AdminFlowOwnerRole) finden und der Besitz neu zuweisen. Das Neuerstellen der Verbindungen lässt sich dabei jedoch nicht vermeiden.²
• Die grundlegende Lösung besteht aus Bestandsaufnahme mit einem Flow-Register, Namenskonventionen und Beschreibungsfeldern, der Verlagerung von Benachrichtigungsidentitäten auf gemeinsame Absender sowie der Gestaltung der Ausführungsidentität wichtiger Flows abseits von Einzelpersonen (Dienstkonten mit Vorsicht; Dienstprinzipale für Kernprozesse).¹¹⁶⁷
• Entscheiden Sie für jeden Flow, ob es sich um ein „persönliches Werkzeug“, einen „Team-Vermögenswert“ oder „Unternehmensinfrastruktur“ handelt, und passen Sie das Gewicht der Verwaltung daran an. Das ist unserer Ansicht nach die realistische Grenzlinie, die Personenabhängigkeit verhindert, ohne die Automatisierung vor Ort abzuwürgen.

Auch wenn aktuell niemand einen Wechsel oder ein Ausscheiden plant, empfehlen wir, einmal als Feuerwehrübung alles bis Kapitel 4 dieses Artikels durchzuspielen. Wenn Sie bei der Bestandsaufnahme Ihrer Flows, dem Design einer Übergabe oder der Entscheidung, ob etwas überhaupt in Power Automate gehört, nicht weiterkommen, melden Sie sich gerne.

Verwandte Artikel

• Geschäftsprozesse mit Power Automate automatisieren ── Cloud-Flows, Desktop-Flows und robuste Fehlerbehandlung
• Einen Genehmigungs-Workflow in Power Automate erstellen ── Papier- und E-Mail-basierte Freigabeprozesse digitalisieren
• Ein System ohne Quellcode und ohne Dokumentation übernehmen ── ein praktisches Vorgehen, um es am Laufen zu halten
• Fehlerbehandlung und Wiederholungsdesign in Power Automate
• Power-Automate-Lizenzierung und die Grenze zwischen Standard- und Premium-Connectoren

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt alles von der Untersuchung der Übergabe von Automatisierungen und Fachsystemen, die nach dem Ausscheiden oder Wechsel eines Mitarbeiters niemand mehr anfassen kann, über Design-Reviews des Power-Automate-Betriebs bis hin zur Überführung von Verarbeitung, die einem Flow entwachsen ist, in ein eigenständiges System.

• Technische Beratung & Design-Review
• Windows-App-Entwicklung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was passiert mit einem Power-Automate-Flow, wenn die Person, die ihn gebaut hat, das Unternehmen verlässt?

Der Flow selbst wird nicht automatisch gelöscht, wenn das Konto der ausscheidenden Person gelöscht wird, und läuft weiter, solange ein Mitbesitzer bestehen bleibt. Allerdings sind die im Flow verwendeten Verbindungen (die Authentifizierung gegenüber SharePoint, Outlook und Ähnlichem) an das Konto der Person gebunden, die sie erstellt hat, sodass Aktionen, die die Verbindungen der ausscheidenden Person nutzen, fehlschlagen, sobald das Konto deaktiviert oder gelöscht wird. Zusätzlich wird ein Flow ohne gültigen Besitzer zu einem „verwaisten Flow“, und ein Flow, der Premium-Funktionen nutzt und dessen Besitzer die Lizenz verloren hat, wird in der Leistung gedrosselt und nach 14 Tagen deaktiviert, wenn nichts unternommen wird. Entscheidend ist, vor dem Ausscheiden Mitbesitzer hinzuzufügen und die Verbindungen auszutauschen.

Kann ein Administrator Flows übernehmen, die eine ausgeschiedene Person gebaut hat?

Ja. Im Power Platform Admin Center wählen Sie die Umgebung aus und öffnen Ressourcen → Flows; dort sehen Sie verwaiste Flows ohne Besitzer und können über Freigeben einen neuen Besitzer hinzufügen. Bei vielen Flows lassen sich diese mit Get-AdminFlow aus dem Verwaltungs-PowerShell-Modul auflisten und mit Set-AdminFlowOwnerRole Mitbesitzer im großen Stil hinzufügen. Beachten Sie jedoch, dass die Übernahme des Besitzes die Verbindungen der ausgeschiedenen Person nicht wieder funktionsfähig macht – Sie müssen zusätzlich in einem separaten Durchgang die Verbindung jeder einzelnen Aktion auf eine Verbindung des neuen Kontos umstellen.

Reicht das Hinzufügen von Mitbesitzern als Maßnahme beim Ausscheiden aus?

Das reicht nicht aus. Ein Mitbesitzer kann einen Flow bearbeiten, stoppen und Besitzer hinzufügen, aber nicht die Anmeldedaten einer von jemand anderem erstellten Verbindung ändern, und eine gemeinsam genutzte Verbindung lässt sich nur innerhalb dieses einen Flows verwenden. Aktionen, die die Verbindungen der ausgeschiedenen Person nutzen, laufen erst dann weiter, wenn ein Mitbesitzer seine eigene Verbindung eingetauscht hat. Auch das Problem, dass Benachrichtigungs-E-Mails weiterhin unter dem Namen der ausgeschiedenen Person verschickt werden, bleibt bestehen – das muss mit Designentscheidungen kombiniert werden: Versand über ein gemeinsames Postfach und die Verlagerung geschäftskritischer Flows auf ein dediziertes Ausführungskonto oder einen Dienstprinzipal als Besitzer.

Sollten wir ein gemeinsames Dienstkonto einrichten, um Flows auszuführen?

Das ist eine Option, aber Microsoft empfiehlt Dienstkonten auf Basis gemeinsam genutzter Benutzerkonten nicht als Best Practice. Da das Kennwort unter mehreren Personen geteilt wird, lässt sich schwer nachvollziehen, wer was geändert hat, und die Kennwortverwaltung selbst ist bereits ein Risiko. Wenn Sie dennoch eines einsetzen, beschränken Sie die Berechtigungen auf das notwendige Minimum und den Zugriff auf wenige Personen. Für geschäftskritische Flows ist ein Dienstprinzipal als Besitzer – der nicht von einem Personenkonto abhängt – der offiziell empfohlene Ansatz, wobei zu beachten ist, dass die Einrichtung IT-Kenntnisse erfordert und bei Nutzung von Premium-Funktionen eine Process-Lizenz nötig ist.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.