Power Automate ohne Portal-Geklicke: Flows mit Claude autonom bauen, testen und fixen

Wer viel mit Power Automate arbeitet, kennt das Ritual: Portal öffnen, richtige Environment wählen, Flow suchen, Designer laden, Schritt für Schritt klicken, testen, in der Run-Historie nach dem roten Lauf suchen, die kaputte Action finden, korrigieren, neu ausführen. Jeder Schritt ein Klick, jeder Kontextwechsel ein Tab. Für einen einzelnen Flow geht das. Für den zehnten an einem Nachmittag nicht mehr.

Microsoft hat dafür seit Kurzem eine offizielle Antwort: das Repo microsoft/power-platform-skills — ein Plugin-Marktplatz für Claude Code und GitHub Copilot CLI. Das darin enthaltene power-automate-Plugin, angetrieben vom FlowAgent MCP, lässt einen KI-Agenten Cloud-Flows anlegen, chirurgisch editieren, ausführen und Runs diagnostizieren — komplett aus dem Terminal. Wir haben es an einer echten Dataverse-Trial-Umgebung durchgespielt. Dieser Beitrag zeigt das Setup, das Environment-Handling und die Praxis — inklusive der unbequemen Stellen.

Was das Paket wirklich ist

Kein neues Portal, sondern ein MCP-Server, der sich in deinen bestehenden KI-Client einklinkt. Der FlowAgent ist ein self-contained Node-Modul (Node 18+, keine externen Dependencies) und spricht die Power-Platform-Endpunkte direkt an. Was danach zur Verfügung steht, ist eine ganze Werkbank:

• Flows: auflisten, holen, anlegen, editieren (auf Action-Ebene), kopieren (auch environmentübergreifend), publishen/deaktivieren, löschen.
• Runs: History, Details, einzelne Actions, cancel/resubmit, Diagnose fehlgeschlagener Läufe.
• Connections & Environments: verwalten, Environment-Routing, Desktop-Flows.

Bedient wird das nicht mit Klicks, sondern mit Sprache: „Bau mir einen Flow, der …”, „führ ihn aus”, „warum ist der letzte Lauf rot?”. Der Agent übersetzt das in die passenden Tool-Aufrufe.

Setup: einmal einrichten

Das Plugin lebt in deinem KI-Client. In Claude Code sind es zwei Zeilen:

/plugin marketplace add microsoft/power-platform-skills
/plugin install power-automate@power-platform-skills

Danach einmal Claude Code neu starten — der MCP-Server wird beim Start registriert, /reload-plugins allein reicht dafür nicht (das war unser erster Stolperstein).

Für die Authentifizierung nutzt der FlowAgent die Azure CLI. Power Platform braucht keine Azure-Subscription, nur den Tenant-Kontext — deshalb reicht ein tenant-weiter Login:

az login --allow-no-subscriptions

Meldet dich mit dem Konto an, das Zugriff auf deine Power-Automate-Umgebung hat. Ein kurzer Preflight bestätigt, dass der Token auch wirklich für Power Automate gilt:

az account get-access-token --resource https://service.flow.microsoft.com --query expiresOn -o tsv

Kommt hier ein Ablaufdatum statt eines AADSTS-Fehlers zurück, steht die Verbindung.

Environment-Routing: wo landen die Flows?

Der erste echte Handgriff: dem Agenten sagen, in welcher Environment er arbeiten soll. Denn Flows sind immer an eine Umgebung gebunden.

Du: Welche Power-Automate-Umgebungen habe ich?

Der Agent ruft list_environments auf und bekommt die Umgebungen zurück (bei uns eine „Sales Trial” mit Dataverse und die Default-Umgebung). Ein Satz genügt, um die Zielumgebung zu fixieren — ab da gehen alle Aufrufe dorthin:

Du: Nimm die Sales-Trial-Umgebung als Standard.

Intern setzt das set_current_env. Wichtig: Der Run-Verlauf (dazu gleich) kommt nur aus Dataverse-Umgebungen — die schlichte Default-Umgebung liefert keine Historie über diesen Weg.

Einen Flow bauen — und ihn absichtlich zerlegen

Jetzt der Kern. Wir lassen den Agenten einen simplen Flow bauen: ein manueller Trigger, dann eine Compose-Action, die rechnet. Der Agent erzeugt daraus eine vollständige Flow-Definition und legt sie mit create_flow an — kein Klick im Portal.

Damit die nächste Stufe etwas zu tun bekommt, lassen wir die Rechnung bewusst durch Division durch null scheitern. Ein Aufruf von run_flow (mit Warten auf das Ergebnis) — und der Lauf kippt sofort auf Failed, Action Berechnung, Fehlercode InvalidTemplate.

Der Agent liest über get_run_details die Run-Historie, benennt die kaputte Action und den Grund, und wendet dann einen chirurgischen Fix an: nur der eine Ausdruck wird korrigiert (div(100, 0) → div(100, 4)), der Rest bleibt unangetastet. Ein erneuter run_flow — und der Lauf ist grün.

Das ist der ganze Loop — bauen → ausführen → Fehler lesen → gezielt fixen → grün — und kein einziger Klick im Designer.

Mehr als eine Zeile: ein Flow mit Condition

Ein Compose beweist nur, dass es geht. Interessant wird es bei echter Logik. Wir haben den Agenten den Business-Flow Urlaubsantrag prüfen Schritt für Schritt aufbauen lassen — und dabei zugeschaut: erst nur der Trigger, dann kommt Antragstage ermitteln (Compose) dazu, danach eine Condition Genehmigung nötig, die prüft, ob die ermittelten Antragstage über 10 liegen, und zuletzt die beiden Zweige — im Ja-Zweig die Vorgesetzten-Freigabe, im Nein-Zweig automatisch genehmigt. Im Designer erscheint Step um Step, während der Agent den Flow über die FlowAgent-Tools wachsen lässt.

Der Chat zum Video

Genau so ist der Flow oben entstanden — ein Auszug aus der Claude-Code-Session, die ihn Schritt für Schritt aufgebaut hat. Jede Zeile mit ⏺ ist ein echter Tool-Aufruf des Power-Automate-Plugins, jede mit ⎿ die Antwort:

# 🧑  Du
#  „Bau in der Sales-Trial-Umgebung einen Flow ‚Urlaubsantrag prüfen': manueller
#   Trigger, Antragstage berechnen, ab 10 Tagen Freigabe beim Vorgesetzten, sonst
#   automatisch — und bau ihn Schritt für Schritt auf."

# 🤖  Claude
#  Klar. Ich starte nur mit dem Trigger und ergänze dann Compose, Condition
#  und die beiden Zweige — Stück für Stück.

⏺ create_flow    name="Urlaubsantrag prüfen"   trigger="manual"
  ⎿ angelegt · id 8d4dae3e · 1 Trigger, noch keine Aktion

⏺ update_flow    + Compose   "Antragstage ermitteln"  = 12
  ⎿ ok · Trigger → Compose

⏺ update_flow    + Condition "Genehmigung nötig":  outputs('Antragstage ermitteln') > 10
  ⎿ ok · Verzweigung eingefügt

⏺ update_flow    + Wenn ja:   "Vorgesetzten Freigabe"
                 + Wenn nein: "Automatisch genehmigen"
  ⎿ ok · Flow vollständig · Validierung grün

# 🤖  Claude
#  Fertig. Vier Schritte, ein zusammenhängender Flow — genau der Aufbau,
#  den du oben im Designer wachsen siehst.

Der Lauf nimmt korrekt den Ja-Zweig (Bestellwert über der Schwelle), der Nein-Zweig wird sauber übersprungen. Wer schon einmal eine Condition im Portal zusammengeklickt hat — Ausdruck wählen, Operator, Wert, dann die beiden Zweige befüllen — weiß, wie viele Klicks das spart.

Der Blick von oben: alles aus dem Editor

Weil jeder Schritt ein Tool-Aufruf ist, entsteht nebenbei ein durchsuchbarer, wiederholbarer Bestand. Der Agent kann jederzeit list_flows über die Umgebung laufen lassen und zeigen, was da ist — inklusive der Flows, die er selbst gerade angelegt hat.

Was hier genau im Einsatz war

Damit das nachvollziehbar — und nachbaubar — ist, der konkrete Stack hinter dem Video:

• Host: Claude Code im Terminal. Der FlowAgent ist ein MCP-Server, andere MCP-fähige Clients (z. B. GitHub Copilot) sprechen dieselben Tools an.
• Plugin: microsoft/power-platform-skills, Plugin power-automate — installiert per /plugin install power-automate@power-platform-skills. Dazu die Skills /setup, /browse-flows, /create-flow, /debug-flow.
• Auth: ein Azure-Zugriffstoken (az account get-access-token) für die Flow- und BAP-Endpunkte; die Umgebung war eine kostenlose Trial.

Die MCP-Tools, die für genau diesen Flow zum Einsatz kamen:

• list_environments / set_current_env — Umgebung wählen (das Environment-Routing von oben)
• create_flow — den Flow mit dem Trigger anlegen
• update_flow — Actions ergänzen: Compose, Condition, die beiden Zweige
• get_flow / set_current_flow — Definition lesen, Arbeitskontext setzen
• run_flow — den Testlauf auslösen
• get_run_history / get_run_details — Läufe und Fehlerdetails lesen (die Basis für den Rot-→-Grün-Fix)
• list_flows — den Bestand der Umgebung zeigen

Jede dieser Zeilen ist ein Tool-Aufruf — genau die, die im Terminal-Auszug oben mit ⏺ markiert sind.

Grenzen und Ehrliches

Ein Werkzeug im echten Test zeigt auch seine Kanten. Damit ihr nicht in dieselben Löcher fallt:

• Zwei Plugin-Bugs (Version 2.0.0). diagnose_run und edit_flow warfen bei uns intern … is not a function. Kein Beinbruch: get_run_details liefert dieselbe Diagnose-Grundlage, und update_flow ersetzt die ganze Definition statt nur einer Action. Der Loop oben lief damit vollständig durch.
• Der neue Flow-Designer streikt teils. Beim Öffnen einzelner Flows kam „Konnten Flow in der neuen Designer-Umgebung nicht laden”. Der Umschalter auf die klassische Designer-Ansicht rendert alles sauber.
• Run-Historie braucht Dataverse. Über den flowRuns-Weg liefern nur Dataverse-gestützte Umgebungen eine Historie; eine reine Default-Umgebung nicht.
• Multi-Tenant-Falle beim Login. Wer mehrere az-Konten (mehrere Tenants) parallel angemeldet hat, kann erleben, dass ein Teil der Aufrufe im falschen (Home-)Tenant landet. Sauberste Kur: nur das gewünschte Konto angemeldet lassen.
• Kein Login-Zauber. Der Agent meldet dich nicht an fremden Diensten an; die Auth (az/MSAL) und passende Lizenzen musst du im Vorfeld bereitstellen.

Fazit

Das Spannende ist nicht, dass ein Agent einen Flow bauen kann — das ist ein Trick. Spannend ist, dass Anlegen, Editieren, Ausführen und Diagnostizieren in derselben Konversation passieren, versioniert und wiederholbar, ohne Kontextwechsel ins Klick-Portal. Für alle, die Power Automate nicht als Hobby, sondern als Handwerk betreiben, verschiebt das offizielle Microsoft-Plugin die Arbeit dahin, wo Entwickler ohnehin sind: in den Editor.

Der Code ist offen: github.com/microsoft/power-platform-skills — das power-automate-Plugin liegt unter plugins/power-automate.