Web-Automatisierung: Portale ohne API anbinden
Power Automate Desktop bindet Portale ohne API per Browser an: Aktionen, Recorder und Grenzen der Web-Automatisierung.
Der Recorder in Power Automate Desktop zeichnet Klicks als Flow-Aktionen auf. Was er kann, wie UIA und MSAA funktionieren und wo er an Grenzen stößt.
Kaum eine Funktion senkt die Einstiegshürde in Power Automate Desktop so stark wie der Recorder. Statt Aktionen einzeln aus der Aktionsliste zu ziehen und Parameter von Hand zu füllen, klicken Sie sich einfach durch den Ablauf, den Sie automatisieren möchten, und der Recorder übersetzt jede Maus- und Tastaturbewegung in eine fertige Flow-Aktion. Für wiederkehrende Klickstrecken in vertrauten Programmen ist das oft der schnellste Weg zum ersten lauffähigen Entwurf.
Genauso wichtig ist aber die ehrliche zweite Hälfte der Geschichte: Der Recorder ist kein Werkzeug, das jede Oberfläche zuverlässig versteht, und er ersetzt keine Nachbearbeitung. Dieser Beitrag zeigt, wie der Recorder technisch funktioniert, was er neben einfachen Klicks noch abdeckt, und wo er laut Microsofts eigener Dokumentation an klare Grenzen stößt, besonders bei komplexen oder exotisch gebauten Benutzeroberflächen.
Sie finden den Recorder direkt in der Symbolleiste des Flow-Designers. Ein Klick auf Rekorder öffnet das Aufnahmefenster, ein weiterer Klick auf Aufzeichnen startet die Erfassung. Ab diesem Moment verfolgt der Recorder Ihre Maus- und Tastaturaktivität im Verhältnis zu den jeweiligen UI-Elementen und wandelt jede Aktion einzeln in einen Schritt um. Während der Aufnahme zeigt ein Textmarker kurz die Meldung „Warten Sie auf Aktion“, bis der Klick tatsächlich erfasst und eingefügt wurde, ein kleines, aber praktisches Signal, dass Sie nicht zu schnell weiterklicken sollten.
Per Rechtsklick auf ein Element öffnen Sie außerdem ein Kontextmenü mit den für dieses Element verfügbaren Aktionen, etwa das Setzen eines Dropdown-Werts oder das Extrahieren von Text. Sobald Sie die Aufnahme mit Fertig abschließen, wandelt Power Automate die aufgezeichneten Schritte automatisch in Desktop-Flow-Aktionen um und legt alle verwendeten Elemente im UI-Elemente-Bereich ab, sodass Sie sie später wiederverwenden können. Details dazu finden Sie in der Microsoft-Dokumentation zum Aufzeichnen von Desktop-Flows.
Nicht jede Windows-Anwendung liefert dieselbe Qualität an Zugänglichkeitsinformationen, deshalb bietet der Recorder zwei Erfassungsmodi an. UI Automation (UIA) ist das moderne, von Microsoft empfohlene Framework und funktioniert besonders zuverlässig bei Anwendungen, die mit WPF, WinForms oder UWP gebaut wurden, es liefert detailliertere Elementinformationen und eine stabilere Hierarchie. Microsoft Active Accessibility (MSAA) ist älter und springt dort ein, wo Anwendungen keine UIA-Elemente bereitstellen, etwa klassische Win32- oder VB6-Programme. Sie wählen den passenden Modus über das Menü „Aufnahmemodus“ im Recorder aus, abhängig davon, welche Anwendung Sie gerade automatisieren.
Der Recorder beschränkt sich nicht auf simple Mausklicks, sondern deckt eine ganze Reihe wiederkehrender UI-Muster gezielt ab:
Manche Anwendungen legen ihre Barrierefreiheits-API gar nicht offen oder bringen andere technische Hürden mit, sodass der reguläre Recorder überhaupt keine Aktionen erfassen kann. Für genau diesen Fall bietet Power Automate die bildbasierte Aufzeichnung an: Statt UI-Elemente über Selektoren zu erkennen, arbeitet dieser Modus mit Bilderkennung und optischer Zeichenerkennung (OCR). Ein Klick auf ein Element erzeugt automatisch einen Bildausschnitt mit editierbarem Namen, und über „Text aus Bild extrahieren“ können Sie zusätzlich einen Textbereich sowie einen stabilen Ankerbereich in der Nähe auswählen, aus dem der Text per Tesseract-OCR-Engine gelesen wird.
Genau hier lohnt sich der Blick in die von Microsoft selbst dokumentierten bekannten Probleme, denn sie zeigen, dass der Recorder bewusst Kompromisse eingeht, keine Wunderlösung ist.
Noch grundsätzlicher wird es, wenn der Recorder oder der Element-Picker eine Anwendung überhaupt nicht erfassen kann. Laut der Microsoft-Problembehandlung zu UI-Automatisierung gibt es dafür zwei typische Ursachen. Erstens können störende Hintergrundprozesse wie das Microsoft Accessory Center oder DesktopBridge die UI-Automatisierung komplett blockieren, hier hilft es, die Prozesse zu beenden und dauerhaft zu deaktivieren. Zweitens, und deutlich schwerer zu umgehen, verwenden manche Desktopanwendungen eigene UI-Frameworks oder Rendering-Methoden, die nicht mit den Standard-Barrierefreiheits-APIs kompatibel sind, auf denen Power Automate aufbaut. Für den Recorder bleiben diese Elemente dann schlicht unsichtbar.
Microsoft nennt für diesen Fall vier Workarounds: Maus zum Bild bewegen, Maus zu Text auf dem Bildschirm per OCR bewegen, den Recorder mit fest codierten Koordinaten arbeiten lassen, oder Maus- und Klickaktionen direkt über feste Koordinaten kombinieren. Wichtig ist dabei der ausdrückliche Hinweis in der Dokumentation: Damit koordinatenbasierte Lösungen zuverlässig funktionieren, müssen Bildschirmauflösung, DPI-Einstellungen und Skalierung zur Laufzeit exakt der Konfiguration aus der Entwicklung entsprechen, und schon kleine Änderungen an der Oberfläche der Anwendung können den Automatisierungsschritt unbrauchbar machen. Microsoft rät deshalb ausdrücklich, solche Flows gründlich auf jeder Zielmaschine zu testen, bevor sie produktiv laufen.
Für einzelne UI-Elemente lässt sich zusätzlich ein Bild als Fallback-Mechanismus hinterlegen, das automatisch einspringt, wenn der reguläre Selektor ein Element zur Laufzeit nicht mehr findet. Auch dieser Sicherheitsnetz-Mechanismus hat klare Grenzen: Bei Datenextraktion und Web-Datenextraktion wird er nicht unterstützt, ebenso wenig bei Aktionen wie „Wenn Fenster enthält“ oder „Warten auf Webseiteninhalt“, sofern dort die Bedingung „Enthält Text“ oder „Enthält keinen Text“ konfiguriert ist. Und wer einen Flow mit Bild-Fallback in einer Power-Automate-Desktop-Version bis einschließlich v2.44 öffnet und speichert, verliert den Bildselektor dauerhaft, eine Wiederherstellung ist laut Microsoft in dem Fall nicht mehr möglich.
Microsoft formuliert es in der eigenen Dokumentation angenehm nüchtern: Der Recorder soll das Grundgerüst eines Flows liefern, die meisten aufgezeichneten Abläufe sollten anschließend überarbeitet werden, um wirklich stabil zu laufen. Bestimmte Aktionstypen wie Bedingungen und Schleifen lassen sich grundsätzlich gar nicht aufzeichnen und müssen im Nachhinein von Hand ergänzt werden. Genau an diesem Punkt trennt sich ein Flow, der einmal im Test funktioniert, von einem, der Monate später noch zuverlässig läuft.
Ob Sie den Recorder selbst für erste Entwürfe nutzen oder sich eine ganze digitale Mitarbeiterin auf Basis von Power Automate bauen lassen, Sie behalten am Ende die Kontrolle darüber, welche Klicks wirklich automatisiert bleiben, welche Selektoren robust genug für den Produktivbetrieb sind und wo ein Bild-Fallback oder eine OCR-Lösung eher ein Risiko als eine Absicherung darstellt.
Nein. Standardmäßig funktioniert der Recorder nur bei Anwendungen, die ihre Elemente über UIA oder MSAA verfügbar machen. Legt eine Anwendung ihre Barrierefreiheits-API gar nicht offen, greift die bildbasierte Aufzeichnung als Notlösung, doch selbst die scheitert bei individuell gerenderten oder stark angepassten Oberflächen manchmal komplett.
UIA ist das modernere, von Microsoft empfohlene Framework mit detaillierteren Elementinformationen, geeignet für die meisten aktuellen Windows-Anwendungen. MSAA ist älter und wird vor allem für Legacy-Software gebraucht, die keine UIA-Elemente bereitstellt, etwa klassische VB6- oder Win32-Programme. Welcher Modus passt, hängt allein von der Zielanwendung ab, nicht von persönlicher Vorliebe.
Meist liegt es an einer von zwei Ursachen: störende Hintergrundprozesse wie das Microsoft Accessory Center oder DesktopBridge, die sich beenden lassen, oder ein UI-Framework der Zielanwendung, das nicht mit den Standard-Barrierefreiheits-APIs kompatibel ist. Im zweiten Fall bleibt oft nur eine koordinaten- oder bildbasierte Lösung als Workaround.
In der Praxis fast immer, und das sagt Microsoft auch selbst so. Der Recorder liefert ein funktionierendes Grundgerüst, aber Bedingungen, Schleifen und robustere Fehlerbehandlung lassen sich nicht aufzeichnen und müssen anschließend manuell im Flow-Designer ergänzt werden.
Nur so zuverlässig wie die Bildschirmumgebung, in der sie läuft. Auflösung, DPI-Einstellungen und Skalierung müssen zur Laufzeit exakt der Entwicklungsumgebung entsprechen, sonst trifft der Klick daneben. Wer bildbasierte Schritte produktiv einsetzt, sollte sie gezielt mit einem Bild-Fallback für einzelne Elemente kombinieren und vor dem Rollout auf jeder Zielmaschine testen.
Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.
Zertifizierungen
Power Automate Desktop bindet Portale ohne API per Browser an: Aktionen, Recorder und Grenzen der Web-Automatisierung.
Cloud Flow oder Desktop Flow? So entscheiden Sie in Power Automate, wenn ein Alt-ERP ohne API im Spiel ist.
n8n ist nicht immer die richtige Wahl. Diese Szenarien zeigen ehrlich, wann Cloud-Limits, Governance oder Betrieb dagegen sprechen.
Der Recorder in Power Automate Desktop zeichnet Klicks zuverlässig auf, scheitert aber regelmäßig an komplexen oder bildbasierten Oberflächen. Wir nehmen die aufgezeichneten Schritte als Ausgangspunkt und bauen daraus einen robusten, produktionsreifen Flow mit stabilen Selektoren. So wird aus der Aufzeichnung eine Automatisierung, die auch im Alltag hält.