Mit Power Automate Geschäftsprozesse automatisieren ── Cloud-Flows und Desktop-Flows richtig einsetzen und Fehlerbehandlung entwerfen

„Jeden Morgen sammelt jemand die CSV-Dateien aus einem Freigabeordner, fasst sie in Excel zusammen und schickt sie per E-Mail an die Vorgesetzten.“ „Werte werden von Hand aus mehreren Fachanwendungen kopiert und eingefügt, nur um eine Zusammenfassung zu erstellen.“ Solche Aufgaben mit Power Automate zu automatisieren, ist eine Anfrage, die uns in letzter Zeit häufig erreicht.

Der erste kleine Flow läuft meist schon nach wenigen Dutzend Minuten. Schwierig wird es erst danach. Sobald der Flow eine Weile in Produktion läuft, bleibt er gelegentlich mit einem Fehler stehen. Eine geringfügige Änderung am Bildschirmlayout des Zielsystems bringt den Flow zum Absturz. Wo das Passwort abgelegt werden soll, wurde nie entschieden, also steht es vorerst direkt als Wert in einer Eingabevariable. Es gibt einen „funktionierenden Flow“, aber wenn es darauf ankommt, kann ihn niemand reparieren — dieses Muster haben wir schon mehrfach erlebt.

Power Automate hat eine niedrige Einstiegshürde und lässt sich No-Code beziehungsweise Low-Code starten. Genau diese Einfachheit macht es aber auch zu einem Werkzeug, bei dem das Design leicht auf später verschoben wird, während der Flow schon in Produktion läuft. Dieser Artikel behandelt in der Reihenfolge, in der Teams in der Praxis am ehesten stolpern: den Unterschied zwischen Cloud-Flows und Desktop-Flows, die Rollenverteilung mit PowerShell und VBA, Fehlerbehandlung, wie sich UI-Automatisierung stabilisieren lässt, den Umgang mit Anmeldeinformationen, Governance und Betrieb sowie den Zeitpunkt, an dem Power Automates Grenzen erreicht sind.

1. Das Wichtigste zuerst

• Power Automate gliedert sich grob in zwei Familien: Cloud-Flows (verbinden Cloud-Dienste über Connectoren) und Desktop-Flows (RPA, das Windows-Bildschirme und Desktop-Anwendungen automatisiert). Zu klären, welche der beiden Sie tatsächlich brauchen, ist die erste Design-Entscheidung.
• Wenn es nur darum geht, einen „wiederkehrenden Arbeitsschritt auf dem PC“ zu automatisieren, ist PowerShell in vielen Fällen die naheliegendere Wahl vor Power Automate Desktop. Ist ein Mausklick oder eine Bildschirmeingabe nicht zwingend nötig, lässt sich PowerShell oft leichter warten und in die Versionskontrolle einbinden.
• Power Automate lohnt sich vor allem, wenn Sie den Bildschirm eines bestehenden Systems mit wenig oder keiner API bedienen müssen, oder wenn Sie mit Microsoft-365-Connectoren (Outlook, SharePoint, Teams usw.) schnell Benachrichtigungs- und Genehmigungs-Flows aufbauen möchten.
• Für den Produktivbetrieb gehören vier Dinge von Anfang an ins Design: Fehlerbehandlung (On Block Error), stabile UI-Selektoren, sichere Verwaltung von Anmeldeinformationen und Governance über DLP-Richtlinien. Nachträglich eingebaut, sind sie eine Quelle für Zwischenfälle.¹²
• Für die unbeaufsichtigte Ausführung (unattended) sind eine andere Lizenz und andere Voraussetzungen nötig als für die beaufsichtigte (attended). Wird die Lizenzplanung aufgeschoben, kann es passieren, dass ein Flow in der Testumgebung läuft, sich aber in Produktion nicht starten lässt.³⁴

2. Der Aufbau von Power Automate

Power Automate ist weniger ein einzelnes Produkt als eine Plattform, die mehrere Automatisierungsmechanismen bündelt.

flowchart TB
    PA[Power Automate]
    PA --> Cloud[Cloud-Flow]
    PA --> Desktop[Desktop-Flow / RPA]
    PA --> Process[Prozess-Mining]
    PA --> Builder[AI Builder]

    Cloud --> Auto[Automatisierter Flow<br/>Ereignisauslöser]
    Cloud --> Sched[Geplanter Flow<br/>regelmäßige Ausführung]
    Cloud --> Instant[Sofort-Flow<br/>manuell / Schaltfläche]
    Cloud --> Connectors[Connectoren<br/>SharePoint / Outlook / Teams / SQL usw.]

    Desktop --> Attended[Beaufsichtigte Ausführung<br/>läuft vor den Augen der Benutzerin/des Benutzers]
    Desktop --> Unattended[Unbeaufsichtigte Ausführung<br/>läuft auf Server/dediziertem PC]
    Desktop --> UIAuto[UI-Automatisierung<br/>Bildschirmsteuerung, Integration bestehender Anwendungen]

• Cloud-Flows verbinden Cloud-Dienste über Connectoren miteinander. Je nach Trigger-Typ unterscheidet man automatisierte Flows (bei Eintreten eines Ereignisses), geplante Flows (regelmäßige Ausführung) und Sofort-Flows (manueller Start).
• Desktop-Flows sind RPA (Robotic Process Automation), die Anwendungen und Bildschirme direkt unter Windows steuern. Sie lassen sich sowohl aus einem Cloud-Flow aufrufen als auch eigenständig ausführen.⁵
• Desktop-Flows unterscheiden sich außerdem in die beaufsichtigte Ausführung (attended), bei der eine Person vor dem Bildschirm sitzt, und die unbeaufsichtigte Ausführung (unattended), die auf einem dedizierten PC oder Server ohne menschliches Zutun läuft.⁴

Eine „dedizierte Maschine“ für die unbeaufsichtigte Ausführung bedeutet mehr, als dass sie nur nicht gesperrt sein darf. Unter Windows 10/11 schlägt eine unbeaufsichtigte Ausführung fehl, sobald die Sitzung irgendeiner Person gesperrt zurückbleibt — unabhängig davon, ob es sich um die für die Verbindung genutzte Person handelt. Unter Windows Server ist der Geltungsbereich etwas enger: Hier verhindert nur eine gesperrte Sitzung derselben Person, die auch die Verbindung nutzt, die Ausführung. Nach Wartungsarbeiten oder einer RDP-Verbindung durch eine andere Administratorin bzw. einen anderen Administrator wird gerne nur „gesperrt“ oder „getrennt“, statt sich vollständig abzumelden — dabei müssen sich wirklich alle „abmelden“.⁶

Bei einer Beratung beginnen wir zunächst damit, zu klären, ob es „um die Verbindung von Cloud-Diensten“ oder „um die Steuerung eines Bildschirms“ geht. Allein das schafft schon deutlich mehr Klarheit.

3. Cloud-Flow, Desktop-Flow, PowerShell und VBA im Vergleich

Auch wenn alle vier unter „Automatisierung“ fallen, unterscheiden sich ihre Stärken erheblich.

Ein in der Praxis häufiges Missverständnis ist die Annahme „Automatisierung nötig = also erst einmal Power Automate“. Ein System, das bereits eine API bereitstellt, mit Power Automate Desktop über die Benutzeroberfläche zu steuern, ist in aller Regel ein Fall, in dem es stabiler wäre, die API direkt aus PowerShell oder .NET anzusprechen. Umgekehrt ist die UI-Automatisierung per Desktop-Flow die realistische Wahl, wenn Sie den Bildschirm eines alten Fachsystems ohne API oder einer Win32-Anwendung bedienen müssen.

Hinweis: Die Grenzen von Excel und VBA sowie Überlegungen zur Ablösung werden auch im separaten Artikel „Was ist VBA? – Grenzen, Zukunftsfähigkeit und realistische Migrationsmuster“ behandelt. Dort geht es auch um das Kombinieren von Geschäftsprozessen auf Microsoft 365 mit Office Scripts und Power Automate.⁷

4. Lizenzierung ── nur das Nötige für die unbeaufsichtigte Ausführung

Der Gesamtüberblick über die Lizenzstruktur (der Umfang der in Microsoft 365 enthaltenen Seed-Lizenzen, die Grenze zwischen Standard- und Premium-Connectoren, ob Premium oder Process günstiger abschneidet, und die AI-Builder-Credits) ist im separaten Artikel „Power-Automate-Lizenzierung ── Wie weit Microsoft 365 kostenlos trägt und wann Premium nötig wird“ mitsamt Entscheidungstabelle zusammengefasst. Hier geht es nur um die drei Punkte, die für den Betrieb der unbeaufsichtigten Ausführung unverzichtbar sind — dem eigentlichen Thema dieses Artikels.³

Wer keine eigene physische Maschine bereitstellen möchte, kann alternativ Power Automate Hosted Process nutzen, das die unbeaufsichtigte Ausführung auf von Microsoft gehosteten Maschinen bzw. Maschinengruppen ermöglicht.⁸

Noch ein Grundsatz, der nicht nur für die unbeaufsichtigte Ausführung gilt: Wessen Lizenz zum Einsatz kommt, hängt nicht davon ab, wer den Flow gebaut hat, sondern davon, wie er gestartet wird (bei automatisierten und geplanten Flows die Eigentümerin bzw. der Eigentümer, bei per Schaltfläche gestarteten Sofort-Flows die ausführende Person, bei unbeaufsichtigter RPA die Maschine). Diese Zuordnung ist in einer Tabelle im oben genannten Lizenzartikel zusammengefasst. In jedem Fall gilt: Wird die Lizenzplanung aufgeschoben, endet das oft damit, dass ein Flow in der Testumgebung läuft, sich aber in Produktion nicht starten lässt — prüfen Sie die drei oben genannten Punkte deshalb bereits in der PoC-Phase.

5. Praxisnahes Design ── CSVs aus einem Freigabeordner auswerten, einen Excel-Bericht erstellen und per E-Mail versenden

Als konkretes Beispiel dient die verbreitete Aufgabe „Erstellung eines Tagesberichts“.

Zunächst zur Natur dieses Kapitels: Es handelt sich nicht um eine Klickanleitung für die Oberfläche, sondern um konzeptionelles Design — wie Aktionsstruktur, Variablen, die Aufteilung in Unterflows und das Aufräumen im Fehlerfall entschieden werden. Die Bildschirmabfolge und Bedienschritte von Power Automate for desktop richten sich am zuverlässigsten nach der offiziellen Dokumentation und der jeweiligen Version, daher beschränkt sich dieser Artikel darauf, „welche Aktion in welcher Granularität mit welcher Variablenübergabe kombiniert wird“. Damit sich das Beispiel möglichst direkt umsetzen lässt, enthält 5.1 eine Variablenliste (Name, Typ, Beispielwert) und 5.2 die Aufteilungsstruktur der Unterflows.

In diesem Artikel werden die Aktionsnamen in der englischen UI-Bezeichnung angegeben. Arbeiten Sie mit einer lokalisierten Oberfläche, ist die Suche nach dem englischen Namen der zuverlässigste Weg, eine Aktion zu finden — die übersetzten Bezeichnungen sind nicht durchgängig eindeutig.

Ziel

1. Die CSV-Dateien des laufenden Tages aus dem Freigabeordner sammeln
2. Die Inhalte auswerten und in die Excel-Berichtsvorlage schreiben
3. Den Bericht im vorgesehenen Ordner speichern
4. Die Beteiligten per E-Mail benachrichtigen
5. Bei einem Fehler die zuständige Person benachrichtigen und die Ursache im Protokoll festhalten

flowchart TD
    Start([Geplanter Start 06:30]) --> Block[[On Block Error: Aggregationsverarbeitung]]
    Block --> List[Get files in folder<br/>CSVs des laufenden Tages abrufen]
    List --> Check{Zieldateien vorhanden?}
    Check -- Nein --> NoticeEmpty[Leeres Ergebnis protokollieren und beenden]
    Check -- Ja --> Read[Read from CSV file<br/>Schleife über jede Datei]
    Read --> Agg[Werte auswerten und in Variablen aufaddieren]
    Agg --> Excel[Launch Excel<br/>Vorlage öffnen]
    Excel --> Write[Write to Excel worksheet<br/>Aggregationsergebnis eintragen]
    Write --> Save[Excel speichern und schließen]
    Save --> Mail[Send an email<br/>Bericht an Beteiligte senden]
    Mail --> Log[Ausführungsergebnis an die Protokolldatei anhängen]
    Log --> End([Erfolgreich abgeschlossen])
    Block -. Fehler aufgetreten .-> Handler[Fehlerbehandlung]
    Handler --> CloseExcel[Excel schließen, falls noch geöffnet]
    CloseExcel --> LogErr[Fehlerdetails im Protokoll festhalten]
    LogErr --> Notify[Fehlerbenachrichtigung per E-Mail an die Administration]
    Notify --> End2([Als fehlgeschlagen protokolliert])

Die wichtigsten Aktionen und ihre Rolle in diesem Flow:

Die übersetzten Aktionsbezeichnungen entsprechen nicht durchgängig einer eindeutigen Eins-zu-eins-Zuordnung — selbst innerhalb der offiziellen lokalisierten Dokumentation schwanken die Übersetzungen für ein und dieselbe Aktion.¹¹ Wenn Sie eine Aktion in der Oberfläche nicht finden, ist die Suche nach dem englischen Namen der zuverlässigere Weg.

5.1 Variablendesign ── Namen, Typen, Beispielwerte

Ob Variablen gut gewählt sind, entscheidet sich daran, ob eine Person, die den Flow später liest, allein anhand des Flows die Bedeutung nachvollziehen kann. Für dieses Beispiel sollten mindestens die folgenden Punkte vorab festgelegt werden. Passen Sie die Werte an Ihre eigene Umgebung an.

Drei Punkte sind entscheidend: Pfade nicht direkt in die Aktion schreiben, sondern in eine Variable auslagern (dann genügt eine einzige Stelle, um zwischen Test- und Produktivumgebung umzuschalten), Datum als „Datum/Uhrzeit-Typ“ und als „Anzeigetext“ getrennt vorhalten (Vergleiche über den Datum/Uhrzeit-Typ, Dateinamen über Text zusammensetzen), sowie stets eine Variable für die Anzahl mitführen (das liefert Material fürs Protokoll und unterscheidet „0 Datensätze, aber erfolgreich beendet“ von „0 Datensätze, weil das Abrufen fehlgeschlagen ist“).

5.2 Aufteilung in Unterflows

Statt den gesamten Flow als eine einzige, riesige Aktionsfolge zu bauen, macht eine Aufteilung nach Verarbeitungseinheiten in Unterflows spätere Änderungen und die erneute Ausführung nur des fehlgeschlagenen Teils erheblich einfacher. Für dieses Beispiel ergibt sich folgende Struktur.

Main (Hauptflow)
  ├─ Initialisierung: Variablen aus 5.1 setzen
  ├─ [On Block Error] Block-Start
  │    ├─ „CSVs sammeln“ ausführen          → Ausgabe: lstFiles
  │    ├─ Bei 0 Zieldateien „Kein Ergebnis“ protokollieren und beenden
  │    ├─ „Auswerten“ ausführen             → Eingabe: lstFiles / Ausgabe: numTotal, numProcessed
  │    ├─ „In Excel schreiben“ ausführen    → Eingabe: numTotal, txtTemplatePath / Ausgabe: txtReportPath
  │    ├─ „Benachrichtigen“ ausführen       → Eingabe: txtReportPath, numProcessed
  │    └─ „Protokollieren“ ausführen        → Eingabe: Ausführungsergebnis (Erfolg)
  └─ [Fehlerbehandlung]
       ├─ „Excel aufräumen“ ausführen (noch offene Instanz schließen)
       ├─ „Protokollieren“ ausführen        → Eingabe: Ausführungsergebnis (Fehler + Fehlerdetails)
       └─ „Benachrichtigen“ ausführen       → Eingabe: Fehlerbenachrichtigung an die Administration

Kriterium für die Aufteilung ist, ob ein Teil auch für sich allein erneut ausgeführt werden kann, ohne zu brechen. Schritte wie „Protokollieren“ oder „Benachrichtigen“, die sowohl vom Erfolgs- als auch vom Fehlerpfad aufgerufen werden, sollten von Anfang an als Unterflow angelegt werden, damit die Logik nicht doppelt gepflegt werden muss. Beginnen die Unterflows dagegen, sich stillschweigend auf globale Variablen zu verlassen, ist das ein Zeichen für eine zu feine Aufteilung — dann sollte man auf eine Granularität zurückgehen, bei der sich alles explizit über Eingaben und Ausgaben übergeben lässt.

Eine Struktur, bei der der Cloud-Flow den zeitgesteuerten Start übernimmt und die eigentliche Verarbeitung an den aufgerufenen Desktop-Flow delegiert, lässt sich im Betrieb ebenfalls gut handhaben.⁵

6. Fehlerbehandlung entwerfen

Power Automate Desktop bietet mit On Block Error eine Aktion, mit der sich die Fehlerbehandlung blockweise gebündelt festlegen lässt. Statt für jede einzelne Aktion ein „Verhalten bei Fehler“ zu konfigurieren, lässt sich so eine gemeinsame Fehlerbehandlung auf alle Aktionen innerhalb eines Blocks anwenden.¹

[On Block Error] Aggregationsblock
  ├─ List files in folder
  ├─ Read from CSV file (Schleife)
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[Fehlerbehandlung]
  ├─ Mit der Aktion Get last error die Fehlerdetails (Name, Auftrittsort, betroffene Aktion, ausführliche Meldung) als Variable abrufen
  ├─ Excel-Instanz schließen, falls noch geöffnet (gerade im Fehlerfall das Aufräumen nicht auslassen)
  ├─ Mit Write text to file (Append) im Protokoll festhalten
  ├─ Mit Send an email (V2) die Administration benachrichtigen
  └─ „Am Ende des Blocks fortsetzen“ oder „Flow-Ausführung stoppen“ wählen

Hier gibt es einige Dinge, die zu beachten sind.

• Die Fehlerbehandlung einer einzelnen Aktion hat Vorrang vor der Fehlerbehandlung des Blocks. Soll sich nur eine bestimmte Aktion anders verhalten, wird sie individuell konfiguriert; alles andere bündelt On Block Error.¹
• Mit „Retry action if an error occurs“ lassen sich vorübergehende Fehler (etwa Netzwerklatenz oder eine gesperrte Datei) automatisch mit einer festgelegten Anzahl und einem festgelegten Intervall erneut versuchen. Alle Fehler pauschal wiederholen zu lassen kostet nur unnötig Zeit — trennen Sie deshalb Fehler, die eine Wiederholung verdienen, von solchen, die es nicht tun (etwa Dateninkonsistenzen).¹
• Um innerhalb der Fehlerbehandlung auf die zuletzt aufgetretene Fehlerinformation zuzugreifen, wird explizit die Aktion Get last error eingesetzt. Sie liefert eine Variable mit sechs Eigenschaften des aufgetretenen Fehlers — Name, Ort, betroffene Aktion, zugehöriger Unterflow, Details und Meldung — und steht nicht automatisch als implizite Variable zur Verfügung. Um zu verhindern, dass derselbe Fehlerwert später versehentlich wiederverwendet wird, empfiehlt es sich, ihn nach dem Abrufen über die Option „Clear error“ zurückzusetzen.¹
• Das Protokoll sollte nicht nur „Erfolg/Fehler“ festhalten, sondern auch die Anzahl der verarbeiteten Datensätze, den Namen der betroffenen Datei und die Fehlermeldung. Der einzige Anhaltspunkt, um im Nachhinein zu klären, „warum der Flow stehen geblieben ist“, ist meist das Protokoll.
• Als Nachbehandlung des Blocks wird explizit entschieden, ob „am Ende des Blocks fortgesetzt“ oder „die Flow-Ausführung gestoppt“ wird. Wird gestoppt, während eine Excel-Instanz noch offen ist, bleibt beim nächsten Lauf ein Prozess zurück — gerade im Fehlerfall lohnt es sich deshalb, das Aufräumen (Schließen der Instanz) bewusst mitzudenken.¹²

Wer mit try/catch/finally aus PowerShell vertraut ist, kann sich den „Block“ von On Block Error als try, die Fehlerbehandlung als catch und die Aufräumschritte als finally vorstellen — das erleichtert den Entwurf.

7. UI-Automatisierung stabilisieren

Die häufigste Ursache für instabile Desktop-Flows liegt meist in der Art, wie UI-Elemente identifiziert werden — dem „Selektor“.

• Standardmäßig zeichnet der UI-Element-Picker ein Bildschirmelement als Selektor auf — eine Kombination von Attributen. Enthält dieser Attribute, die bei App-Updates oder Änderungen der Anzeige leicht brechen (etwa fortlaufende Indizes oder dynamisch erzeugte IDs), kann der Flow auch dann versagen, wenn der Bildschirm unverändert aussieht.¹³
• Werden sich ändernde Attribute statt mit Equals mit Contains oder einem regulären Ausdruck geprüft und Werte, die vom Ergebnis einer vorherigen Aktion abhängen, in Variablen ausgelagert, entstehen dynamischere und robustere Selektoren.¹³
• Sind mehrere Selektoren konfiguriert, springt der Flow beim Fehlschlagen des ersten automatisch zum nächsten. Für kritische Schritte lohnt es sich, einen Ersatzselektor bereitzuhalten, um die Stabilität zu erhöhen.¹³
• Bricht ein Selektor, lässt sich mit der Funktion Repair selector automatisch ein Reparaturvorschlag erzeugen. Es lohnt sich, das zuerst zu versuchen, bevor der Selektor manuell von Grund auf neu erstellt wird.¹³
• Bildschirmwechsel und das Starten von Anwendungen brauchen ihre Zeit. Statt sich nur auf ein festes Wait zu verlassen, sollten bedingte Wartebedingungen wie „auf Fenster warten“ oder „warten, bis UI-Element gefunden wird“ kombiniert und zusätzlich eine automatische Wiederholung für den Fall konfiguriert werden, dass ein UI-Element nicht gefunden wird.¹⁴
• Bei Automatisierungszielen, die sich partout nicht stabilisieren lassen (virtualisierte Bildschirme, Bildschirme mit häufig wechselndem Layout usw.), sollte nicht stur an der UI-Steuerung festgehalten werden — prüfen Sie zuerst, ob API-Aufrufe, Dateiaustausch oder Datenbankzugriff einen stabileren Integrationsweg bieten.

Eine UI-Automatisierung zum ersten Mal zum Laufen zu bringen, ist an sich nicht schwer. Ob sie auch noch nach einem halben Jahr unbeschadet funktioniert, entscheidet sich fast ausschließlich daran, wie sorgfältig die Selektoren gebaut wurden.

8. Anmeldeinformationen sicher handhaben

Der Umgang mit Anmeldeinformationen (Passwörtern, API-Schlüsseln, Verbindungszeichenfolgen usw.) ist bei der Geschäftsprozessautomatisierung die häufigste Quelle für Zwischenfälle.

• Vermeiden Sie es, Passwörter oder Verbindungsdaten direkt als Wert in eine Eingabevariable eines Flows zu schreiben. Mit der Aktion Get credential lassen sich Anmeldeinformationen sicher aus den „Power-Automate-Anmeldeinformationen“ abrufen, die im Hintergrund Azure Key Vault oder CyberArk als Secret-Speicher nutzen; der abgerufene Wert wird als vertraulich markiert und erscheint auch nicht im Ausführungsprotokoll des Flows.¹⁵¹⁶
• Wird Azure Key Vault als Ablage für Secrets genutzt, lässt sich die Verbindungsinformation zu Key Vault auf Power-Automate-Seite an einer einzigen Stelle verwalten, statt Anmeldeinformationen über jeden einzelnen Flow zu verstreuen.¹⁶
• Für die unbeaufsichtigte Ausführung sollte ein dediziertes Konto mit auf das Nötigste beschränktem Zugriff eingerichtet werden, statt ein Konto zu verwenden, das eine Person auch im Alltag nutzt. Je weiter die Berechtigungen eines Kontos reichen, desto größer der Schaden, den ein Fehler oder eine Fehlkonfiguration im Flow anrichten kann.
• Wird ein Passwort „nur vorübergehend, damit es läuft“ im Klartext in eine Eingabevariable geschrieben und die Tests darauf aufgebaut, bleibt es erfahrungsgemäß genau so bis in die Produktion stehen. Sicherer ist es, sich von Beginn der Tests an die Verwendung der Get-credential-Aktion anzugewöhnen.

9. Governance und Betrieb

Sobald sich die Anzahl der von Einzelpersonen oder einzelnen Teams gebauten Flows häuft, wird als Nächstes eine organisationsweite Steuerung notwendig.

• Data-Loss-Prevention-Richtlinien (DLP) klassifizieren die in Flows und Apps nutzbaren Connectoren als „nur Geschäftsdaten“, „keine Geschäftsdaten“ oder „blockiert“ und verhindern, dass ein Connector für Geschäftsdaten und ein Connector ohne Geschäftsdaten innerhalb desselben Flows kombiniert werden. Das ist die Governance-Maßnahme, die zuerst eingerichtet werden sollte, um zu verhindern, dass Daten der Organisation unbeabsichtigt an einen externen Dienst abfließen.¹⁷
• Auch Aktionen von Desktop-Flows lassen sich innerhalb desselben DLP-Rahmens klassifizieren und blockieren, allerdings ist das standardmäßig nicht aktiviert. In den Mandanteneinstellungen des Power Platform Admin Centers muss „Show desktop flow actions in DLP policies“ einmalig eingeschaltet werden — diese Einstellung lässt sich anschließend nicht mehr rückgängig machen. Auch nach der Aktivierung sind nur die Module und Aktionen erfasst, die eine Richtlinie explizit klassifiziert; „eine DLP-Richtlinie eingerichtet“ bedeutet also nicht automatisch, dass der gesamte Desktop-Flow unter Kontrolle steht.²
• Maschinen für die unbeaufsichtigte Ausführung sollten als Maschinengruppen gebündelt verwaltet werden, sodass klar ist, welcher Flow auf welcher Maschine läuft.
• Legen Sie fest, wo der Ausführungsverlauf eingesehen wird. Für einen einzelnen Cloud-Flow lässt sich nach der Anmeldung bei Power Automate über „Meine Flows“ → betroffener Flow → „Ausführungsverlauf“ auf der Detailseite eine fehlgeschlagene Ausführung auswählen und an welcher Aktion sie gescheitert ist samt Fehlerdetails einsehen. Im oberen Menü derselben Detailseite zeigt „Analytics“ Erfolgs- und Fehlerquote sowie den Ausführungsverlauf der letzten 30 Tage. Um Fehler mandanten- bzw. umgebungsweit lückenlos zu sehen, ist Monitor im Power Platform Admin Center am umfassendsten.¹⁸¹⁹ Da Kaskadenfehler auftreten (bei denen Folgeaktionen nur deshalb als fehlgeschlagen gelten, weil eine vorherige Aktion bereits gescheitert ist), gilt als Grundsatz, im Ausführungsverlauf auf die zuerst fehlgeschlagene Aktion zu achten.¹⁸
• Kennen Sie die Grenzen der Standard-Fehlerbenachrichtigung und ergänzen Sie eine eigene. Power Automate versendet bei fehlgeschlagenen Cloud-Flows zwei Arten von E-Mails. Die eine ist eine Fehlerwarnung je Ausführung, die nur dann an Eigentümerin/Eigentümer und Miteigentümer/-innen des Flows geht, wenn sich die Ursache als „bekannt und behebbar“ einordnen lässt (etwa eine unterbrochene Verbindung oder Drosselung). Sie muss außerdem in den Flow-Einstellungen aktiviert sein, und für denselben Flow gilt danach eine Abkühlphase von 28 Tagen. Die andere ist ein wöchentlicher Sammelbericht, der auch allgemeine Fehler ohne ausgelöste Warnung bündelt.¹⁸ Mit den Standardfunktionen allein lässt sich also „jedes Mal, sofort, an die zuständige Person“ nicht erreichen. Binden Sie deshalb eine Benachrichtigung per E-Mail oder Teams an die Administration aus der Fehlerbehandlung in Kapitel 6 als festen Bestandteil des Flows selbst ein.
• Soll ein Cloud-Flow auf lokale Ressourcen zugreifen, die die Cloud nicht direkt erreicht — etwa eine Datenbank oder Dateifreigabe im internen Netzwerk —, kommt das On-Premises-Datengateway zum Einsatz. Das Gateway benötigt auf Cloud-Seite keinen geöffneten eingehenden Port und überbrückt Daten sicher allein über eine ausgehende Verbindung.²⁰
• Werden Test- und Produktivumgebung als getrennte Umgebungen geführt und Desktop-Flows sowie Verbindungsinformationen je Umgebung isoliert, lässt sich verhindern, dass Änderungen während der Tests auf Produktiv-Flows durchschlagen.

10. Grenzen von Power Automate und Eskalationskriterien

Power Automate ist leistungsfähig, aber nicht allmächtig. In den folgenden Situationen lohnt sich der Wechsel zu PowerShell oder einer .NET-Anwendung.

Wenn sich das Gefühl einstellt, „was mit Power Automate gebaut wurde, ist gewachsen und zu komplex geworden“, ist es meist wartungsfreundlicher, nicht stur weiter am Flow zu erweitern, sondern die Kernlogik nach .NET oder PowerShell auszulagern und Power Automate nur noch für Trigger und Benachrichtigungen einzusetzen. Ein praktisches Beispiel für automatisierte Log-Untersuchung und Archivierung mit PowerShell wird im separaten Artikel „PowerShell-Skripte in der Praxis ── Protokollauswertung, Archivierung und Reporting sicher automatisieren“ vorgestellt.

11. Zusammenfassung

Power Automate ist bis zum ersten Schritt erstaunlich einfach. Doch dieselbe Leichtigkeit bedeutet umgekehrt auch, dass ein Flow selbst dann erst einmal läuft, wenn das Design abgekürzt wurde. Ob sich ein in Produktion gebrachter Flow langfristig warten lässt, entscheidet sich fast vollständig daran, wie viele der unscheinbaren Entscheidungen vorab getroffen wurden.

Ob Cloud-Flow oder Desktop-Flow zum Einsatz kommt, und welche Verarbeitung besser PowerShell oder .NET überlassen bleibt — wird diese Abgrenzung vorab geklärt, sinkt der spätere Nacharbeitsaufwand deutlich. Fehlerbehandlung, UI-Selektoren, Anmeldeinformationen, Lizenzierung und DLP-Richtlinien sind allesamt weitaus günstiger, wenn sie „von Anfang an eingebaut“ statt „nachträglich repariert“ werden. Und ob die Entscheidung fällt, gewachsene und komplex gewordene Flows nicht stur weiter auszubauen, sondern Verarbeitung nach .NET oder PowerShell auszulagern, entscheidet ebenfalls darüber, ob sich ein Flow langfristig weiter nutzen lässt.

Zwischen einem „Flow, der irgendwie läuft“ und einem „Flow, dem man sich beruhigt anvertrauen kann“ liegt genau dieser Unterschied im Design. Je mehr eine Automatisierung mit bestehenden Fachsystemen oder Excel-/VBA-Beständen verwoben ist, desto stärker bestimmen die anfänglichen Design-Entscheidungen die späteren Wartungskosten.

Verwandte Artikel

• Was ist VBA? – Grenzen, Zukunftsfähigkeit und realistische Migrationsmuster
• PowerShell-Skripte in der Praxis ── Protokollauswertung, Archivierung und Reporting sicher automatisieren
• Excel-Berichtsausgabe erstellen - COM/Open XML/Vorlagen

Verwandte Beratungsleistungen

Die KomuraSoft LLC berät zur schrittweisen Automatisierung und Modernisierung bei laufendem Erhalt bestehender Excel-, VBA- und Windows-Fachanwendungen sowie zu Design-Reviews von Automatisierungsplattformen einschließlich Power Automate.

• Nutzung und Migration bestehender Assets
• 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.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

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

Wie wähle ich zwischen Cloud-Flow und Desktop-Flow?

Cloud-Flows verbinden Cloud-Dienste über Connectoren miteinander und eignen sich für Genehmigungs-Flows, Benachrichtigungen, SaaS-Integrationen und Geschäftsprozesse rund um Microsoft 365. Desktop-Flows sind RPA, die Anwendungen und Bildschirme direkt unter Windows steuern, und sind die realistische Wahl, wenn Sie alte Fachanwendungen ohne API oder Win32-Anwendungen über die Benutzeroberfläche bedienen müssen. Bei einer Beratung lohnt es sich, zunächst zu klären, ob es um die Verbindung von Cloud-Diensten oder um die Steuerung eines Bildschirms geht — das schafft von Anfang an Klarheit.

Sollte ich Power Automate oder PowerShell verwenden?

Wenn Sie lediglich einen wiederkehrenden Arbeitsschritt auf dem PC automatisieren möchten und Mausklicks oder Bildschirmeingaben nicht zwingend erforderlich sind, ist PowerShell oft die besser wartbare Wahl und lässt sich leichter mit Git versionieren. Für Systeme, die bereits eine API bereitstellen, ist es in der Regel stabiler, diese API direkt aus PowerShell oder .NET anzusprechen, statt sie per UI-Automatisierung zu bedienen. Auch die Verarbeitung von mehreren Hunderttausend Datensätzen, komplexe Logik, die automatisierte Tests braucht, und hochfrequente Dauerprozesse liegen eher bei PowerShell oder .NET. Wird ein Flow zu komplex, lohnt es sich meist, die Kernlogik herauszulösen und Power Automate nur noch für Trigger und Benachrichtigungen einzusetzen — das lässt sich langfristig leichter warten.

Welche Lizenz brauche ich für die unbeaufsichtigte Ausführung in Power Automate?

Für die unbeaufsichtigte Ausführung ist eine andere Lizenz nötig als für die beaufsichtigte: die Power-Automate-Process-Lizenz, die an einen Flow oder eine Maschine gebunden wird. Das frühere Add-on für unbeaufsichtigte Ausführung gilt als Legacy und wurde durch die Process-Lizenz ersetzt. Die Process-Lizenz allein ersetzt jedoch keine Benutzerlizenz: Die Registrierung der Maschine muss durch einen Benutzer mit einer Power-Automate-Premium-Lizenz erfolgen. Zudem schlägt die unbeaufsichtigte Ausführung unter Windows 10/11 fehl, wenn die Sitzung irgendeiner Person noch gesperrt ist — deshalb müssen sich alle vollständig abmelden.

Warum wird die UI-Automatisierung in Desktop-Flows instabil?

Die häufigste Ursache liegt in der Art, wie UI-Elemente identifiziert werden — dem Selektor. Enthält er Attribute, die sich leicht ändern, etwa fortlaufende Indizes oder dynamisch erzeugte IDs, bricht der Flow, obwohl der Bildschirm unverändert aussieht. Als Gegenmaßnahme sollten sich ändernde Attribute statt mit Equals mit Contains oder einem regulären Ausdruck geprüft werden; außerdem lassen sich mehrere Selektoren als Fallback konfigurieren, und bei einem defekten Selektor liefert die Funktion Repair selector automatisch Reparaturvorschläge. Wichtig ist auch, sich nicht allein auf feste Wait-Aktionen zu verlassen, sondern bedingte Wartebedingungen einzusetzen. Ob eine Automatisierung auch nach einem halben Jahr noch zuverlässig läuft, hängt fast ausschließlich davon ab, wie sorgfältig die Selektoren gebaut wurden.

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.