CONSULTING BRIEFING

22.07.2026 · boddenberg.de

Power Automate: neue Cloud Flows mit KI-Integration

Executive Summary

Power Automate hat 2026 die Seite gewechselt. Was jahrelang ein braver Regel-Roboter war – wenn Mail, dann Teams-Nachricht – bekommt in Release Wave 1 eine Denkabteilung eingebaut. Cloud Flows rufen jetzt Copilot-Studio-Agenten als ganz normale Aktion auf, Desktop Flows lassen sich umgekehrt aus Copilot Studio heraus starten, und darunter liegt Dataverse als Fundament für alles, was später einmal nach Anwendungslebenszyklus aussehen soll.

Das Lieferfenster läuft von April bis September 2026, und die Hälfte ist durch. Advanced Connector Policies sind seit dem 4. Juni 2026 allgemein verfügbar, objektzentriertes Process Mining seit dem 5. Juni, Versionskontrolle für Desktop Flows seit dem 13. Mai. Für Juli stehen Flow Groups und die Wiederherstellung gelöschter Flows an, im August folgt ein neues Lizenz-Dashboard.

Die unbequeme Nachricht steckt nicht in der Technik, sondern in der Rechnung und in der Governance. Ein klassischer Cloud Flow läuft weiter auf deiner Power-Automate-Lizenz. Sobald aber eine Agent-Aktion mitspielt, tickt ein zweiter Zähler in Copilot Credits. Und die neue Konnektor-Governance dreht das bisherige Prinzip um: Statt zu sortieren, was geschäftlich und was privat ist, ist ab sofort erst einmal alles blockiert. Wer diese Reihenfolge nicht versteht, schaltet an einem Dienstagmorgen versehentlich die halbe Fachabteilung ab.

Worum geht es im Detail?

Die Grenze zwischen Flow und Agent verschwimmt. Bisher galt eine einfache Arbeitsteilung: Power Automate macht das Stumpfe, Copilot macht das Schlaue, und dazwischen lag eine Schlucht aus Custom Connectors und Azure-Functions-Bastelei. Diese Schlucht ist zugeschüttet. Copilot Studio liefert Aktionen, die im Cloud Flow stehen wie jede andere Aktion auch. Der Flow übergibt Kontext an den Agenten, der Agent liest Wissensquellen, argumentiert sich durch den Fall und gibt ein Ergebnis zurück – der Flow macht danach deterministisch weiter. Umgekehrt kann ein Agent einen Desktop Flow anstoßen, wenn eine Aufgabe exakte, schrittweise Ausführung braucht. Also immer dann, wenn das Zielsystem aus dem vorigen Jahrtausend stammt und den Zeitgeist ebenso verpasst hat wie die Idee einer Programmierschnittstelle.

Abbildung 1: Die drei Schichten eines KI-Flows – Trigger, deterministische Orchestrierung, KI-Zweige. Darunter Dataverse, darüber die Governance-Klammer.

Cloud Flow ist nicht gleich Agent Flow. Der eine ist ein Cloud Flow, der eine KI-Aktion aufruft. Der andere ist ein Agent Flow, den der Trigger „When an agent calls the flow“ startet. Der Unterschied klingt nach Wortklauberei, kostet aber echtes Geld: Cloud Flows bleiben unter Power-Automate-Lizenzierung und sind der Copilot-Studio-Abrechnung nicht unterworfen. Agent Flows werden mit 13 Copilot Credits je 100 Aktionen berechnet. Kostenfrei bleiben sie nur, wenn der interagierende Nutzer mit einer Microsoft-365-Copilot-Lizenz authentifiziert ist. Credits kaufst du entweder als Capacity Pack – 200 US-Dollar für 25.000 Credits, macht 0,008 Dollar je Credit – oder als Pay-as–you-go zu einem Cent je Credit über eine Azure-Abrechnungsrichtlinie. Das klingt nach Kleingeld, bis jemand einen Agent-Flow an einen Postfach-Trigger hängt.

Abbildung 2: Drei Wege zum selben Ergebnis – und drei unterschiedliche Zähler, die dabei mitlaufen.

Dataverse ist keine Option mehr, sondern die Eintrittskarte. Nichts davon funktioniert vernünftig, wenn deine Flows im persönlichen Bereich einzelner Mitarbeiter liegen. Microsoft hat deshalb die Umgebungseinstellung „Flows in Dataverse solutions by default“ gebaut: Jeder neue Cloud Flow landet automatisch in einer Dataverse-Lösung. Damit bekommst du Connection References, Environment Variables, rollenbasierte Sicherheit, die Dataverse-API und lösungsbasiertes Anwendungslebenszyklus-Management. Ohne das bleibt jeder Flow ein Einzelstück mit Besitzernamen – und wenn dieser Besitzer das Unternehmen verlässt, verlässt der Genehmigungsprozess für Reisekosten es gleich mit.

Der Agent, der dazulernt. Am Rand der Ankündigungen, aber strategisch der interessanteste Punkt: Agenten lernen inzwischen aus Korrekturen. Jede Korrektur, die über den Agent Feed eingeht, wird als strukturiertes Gedächtnis gespeichert und auf künftige Läufe angewendet, gesteuert über ein Modell aus Worker und Supervisor. Microsoft startet damit bei Datenerfassungsszenarien. Für dich heißt das: Der Agent von übermorgen verhält sich nicht mehr wie der von heute – und zwar ohne dass jemand eine Konfiguration angefasst hätte. Das ist genau so großartig und so beunruhigend, wie es klingt, und es ist der Grund, warum du Stichproben brauchst statt einmaliger Abnahme.

Was diesen Sommer wirklich ankommt. Vier Dinge stehen in Wave 1 konkret für Cloud Flows an. Flow Groups verteilen die Kapazität einer Process-Lizenz auf bis zu 25 Cloud Flows; Voraussetzung sind verfügbare Process-Lizenzen in der Umgebung, Flows innerhalb von Lösungen und entsprechende Maker-Rechte. Gelöschte Flows stellst du 21 Tage lang direkt im Portal wieder her, als Besitzer, Mitbesitzer oder Umgebungsadministrator – ohne PowerShell, ohne Management-Connector, ohne Support-Ticket. Im August kommt ein überarbeitetes Lizenz-Dashboard, das den Verbrauch endlich sichtbar macht. Und im neuen Designer siehst du Eigenschaftswerte direkt inline aufgeklappt, was die Fehlersuche vom Ratespiel zur Arbeit befördert.

Abbildung 3: Die Meilensteine der Release Wave 1 im Zeitverlauf. Der orange Balken markiert, was am 21.07.2026 bereits ausgeliefert ist.

Was sind Chancen? Was sind Risiken?

Die Chance ist echt und sie ist groß. Prozesse, die bisher an einer unstrukturierten Stelle scheiterten – eine Freitext-Mail, ein schlecht gescanntes PDF, eine Reklamation ohne Kategorie – lassen sich jetzt durchgängig automatisieren. Der deterministische Teil bleibt im Flow, wo er hingehört und wo ihn ein Prüfer noch lesen kann. Der unscharfe Teil wandert in den Agenten. Das ist architektonisch sauberer als fast alles, was wir in den letzten fünf Jahren an KI in Geschäftsprozessen gesehen haben.

Dazu kommt der Governance-Sprung. Das Power Platform Inventory erfasst inzwischen, welche Konnektoren und welche einzelnen Konnektor-Operationen jede Canvas App, jede modellgetriebene App, jeder Cloud Flow, jeder Agent Flow und jeder Agent tatsächlich verwendet – abfragbar über eine API. Zum ersten Mal kannst du die Frage „Wer schreibt eigentlich in dieses System?“ beantworten, ohne drei Wochen lang zu inventarisieren.

Drei Fallen. Erstens die Reichweite: ACP gilt derzeit nur für zertifizierte Konnektoren und MCP-Konnektoren. Custom Connectors und HTTP-Konnektoren sind noch nicht dabei, dafür brauchst du weiterhin klassische Datenrichtlinien und Connector Endpoint Filtering. Virtuelle Konnektoren wird ACP nie unterstützen. Wer also glaubt, mit ACP sei das Thema erledigt, hat ausgerechnet die Lücke offen gelassen, durch die erfahrungsgemäß die interessanten Daten abfließen.

Zweitens das Entfernen: Nimmst du eine Regel aus einer Umgebungsgruppe heraus oder eine Umgebung aus der Gruppe, behalten die betroffenen Umgebungen ihre zuletzt angewandte ACP-Konfiguration. Das ist Absicht – Microsoft will keine Lücke, in der Konnektoren unbemerkt wieder freigeschaltet werden. Für dich heißt das: Aufräumen geht nur je Umgebung oder über die Power Platform API. Drittens die Blockierbarkeit: Nur in Managed Environments lässt sich wirklich jeder Konnektor und jede Aktion blockieren, auch die sonst nicht blockierbaren. In nicht verwalteten Umgebungen bleiben die Ausnahmen Ausnahmen.

Und dann ist da noch das Risiko, das in keiner Feature-Liste steht: Agenten sind nicht deterministisch. Ein Cloud Flow, der zehntausendmal dasselbe tut, ist prüfbar. Ein Agent, der zehntausendmal argumentiert, ist es nicht. Wenn dieser Agent Rechnungen freigibt, Verträge einordnet oder Kunden antwortet, brauchst du Protokollierung, Stichproben und eine klare Grenze, ab welchem Betrag ein Mensch draufschaut. Sonst automatisierst du nicht deinen Prozess, sondern dein Haftungsrisiko – und das skaliert erfahrungsgemäß hervorragend.

Was müssen wir jetzt schon vorbereiten?

Die gute Nachricht: Das meiste davon ist Hausaufgabe, keine Raketentechnik. Die schlechte: Hausaufgaben macht bekanntlich niemand freiwillig.

Inventur ziehen. Nutze das Power Platform Inventory und frage über die API ab, welche Konnektoren und Operationen tatsächlich im Einsatz sind. Diese Liste ist die Grundlage deiner späteren Allowlist. Ohne sie rätst du.

Verwaiste Flows einsammeln. Alles, was einer Einzelperson gehört und außerhalb einer Lösung liegt, ist ein Ausfall mit Terminvorbehalt. Schalte die Umgebungseinstellung für Dataverse-Lösungen ein, damit neue Flows gar nicht erst falsch entstehen.

ACP im Mixed Mode pilotieren. Fang mit einer einzelnen, gut beobachteten Umgebung an. Die klassischen Richtlinien bleiben aktiv, es greift jeweils die restriktivere Einstellung. Erst wenn die Allowlist vollständig ist, denkst du über den ACP-only-Modus nach.

Umgebungsstrategie klären. Produktion, Test und Entwicklung getrennt, keine Entwicklung in der Standardumgebung, Änderungen nur über verwaltete Lösungen aus der Pipeline. Das war schon 2023 richtig und ist mit Agenten im Spiel nicht mehr verhandelbar.

Credit-Budget festlegen. Kaufe Capacity Packs bewusst, statt Pay-as–you-go unbewusst laufen zu lassen, und lege fest, welche Abteilung welchen Verbrauch verantwortet. Das Lizenz-Dashboard im August hilft dabei – allerdings nur, wenn jemand hineinschaut.

Freigabegrenzen definieren. Halte fest, welche Entscheidungen ein Agent allein treffen darf und ab wann ein Mensch gegenzeichnet. Schriftlich, vor dem ersten Produktivlauf, nicht danach im Krisenmeeting.

Häufig gestellte Fragen

Brauche ich Copilot Credits, wenn ich einfach nur einen Cloud Flow baue?

Nein. Klassische Cloud Flows laufen weiterhin unter der Power-Automate-Lizenzierung und unterliegen nicht der Copilot-Studio-Abrechnung. Credits werden erst fällig, sobald der Flow tatsächlich KI-Aktionen ausführt oder als Agent Flow von einem Agenten aufgerufen wird – dann mit 13 Copilot Credits je 100 Aktionen.

Was passiert mit unseren bestehenden DLP-Richtlinien, wenn wir Advanced Connector Policies aktivieren?

Zunächst nichts: ACP startet im Mixed Mode und läuft parallel zu den klassischen Datenrichtlinien, wobei jeweils die restriktivere Einstellung durchgesetzt wird. Erst wenn du bewusst in den ACP-only-Modus wechselst, werden die klassischen Richtlinien ignoriert – gelöscht werden sie dabei allerdings nicht.

Kann ich einen versehentlich gelöschten Flow selbst wiederherstellen?

Ja, seit Juli 2026 innerhalb von 21 Tagen direkt im Power-Automate-Portal. Berechtigt sind Besitzer, Mitbesitzer und Umgebungsadministratoren; der früher nötige Umweg über den Power Automate Management Connector oder PowerShell entfällt.

Lohnen sich Flow Groups für uns?

Wenn du mehrere Flows mit mittlerem Volumen betreibst, die einzeln keine eigene Process-Lizenz rechtfertigen, ja – eine Process-Lizenz lässt sich damit auf bis zu 25 Cloud Flows verteilen. Voraussetzung sind verfügbare Process-Lizenzen in der Umgebung und Flows, die in Dataverse-Lösungen liegen.

Müssen unsere Umgebungen Managed Environments sein?

Für den Einstieg nicht: ACP lässt sich auf einzelnen Umgebungen auch ohne Managed Environments konfigurieren, damit jeder von den klassischen Datenrichtlinien migrieren kann. Willst du aber wirklich jeden Konnektor und jede Aktion blockieren, auch die standardmäßig nicht blockierbaren, oder Richtlinien über Umgebungsgruppen ausrollen, brauchst du Managed Environments und damit Premium-Lizenzierung.