Der entscheidende Punkt: Power Automate wohnt dort, wo Ihre Daten und Ihre Mitarbeitenden ohnehin sind. Wer SharePoint, Outlook, Teams, Excel und OneDrive nutzt, hat die Standard-Connectoren bereits in vielen M365-Plänen enthalten und kann einfache Cloud-Flows ohne zusätzliche Lizenz starten. Diese Nähe zum Bestand ist Power Automates größter Vorteil gegenüber spezialisierten Automatisierungs-Diensten – und zugleich die Quelle der häufigsten Missverständnisse, weil „in M365 enthalten“ eben nicht „alles kostenlos“ bedeutet.
Power Automate ist 2016 aus „Microsoft Flow“ hervorgegangen und seither in mehreren Schritten erweitert worden: erst um Desktop-Automatisierung (RPA) durch die Übernahme von Softomotive und das Produkt Power Automate Desktop, dann um KI-Funktionen über AI Builder und zuletzt um den Copilot, der Flows in natürlicher Sprache beschreibbar macht. Die Plattform deckt heute ein Spektrum ab, das von der simplen „Wenn-dann“-Regel bis zur unternehmensweit betriebenen Roboter-Flotte reicht.
Power Automate steht selten allein. Es ist der Automatisierungs-Motor einer vierteiligen Familie: Power Apps baut Oberflächen und Anwendungen, Power BI visualisiert Daten, Power Pages liefert externe Portale, und Copilot Studio erstellt KI-Agenten. Power Automate verbindet diese Bausteine im Hintergrund – eine in Power Apps erfasste Anfrage löst einen Flow aus, dieser schreibt nach Dataverse, benachrichtigt über Teams und stößt eine Genehmigung an. Geteilte Basis ist Dataverse, Microsofts gemeinsame Datenplattform, und die Connector-Bibliothek, die alle Power-Platform-Dienste teilen.
Diese Verzahnung erklärt, warum Power Automate für Microsoft-Häuser meist die wirtschaftlich richtige Wahl ist: Man kauft keinen isolierten Dienst, sondern erweitert eine Plattform, die ohnehin vorhanden ist. Wer hingegen keinen Microsoft-Stack betreibt, kauft sich mit Power Automate auch ein Stück M365- und Dataverse-Gravitation ein, die nicht zu jedem Haus passt.
Cloud Flows sind die erste Wahl, wann immer ein System eine Schnittstelle bietet. Sie folgen dem Muster Auslöser/Aktion: Ein Trigger startet den Ablauf – eine neue E-Mail, ein angelegtes SharePoint-Element, ein Zeitplan, ein Webhook – und eine Kette von Aktionen erledigt den Rest. Power Automate unterscheidet automatisierte Flows (durch Ereignisse ausgelöst), geplante Flows (zeitgesteuert) und Instant Flows (per Knopfdruck oder aus einer App heraus gestartet). Weil Cloud Flows über stabile APIs arbeiten, sind sie unempfindlich gegenüber Oberflächen-Änderungen und damit die wartungsärmste Variante.
In der Praxis decken Cloud Flows den Großteil aller Automatisierungs-Bedarfe ab: Datei- und Datenablage, Benachrichtigungen, Genehmigungsketten, das Synchronisieren von Listen, das Anlegen von Datensätzen. Die Kunst liegt weniger in der Technik als im Prozessdesign – ein gut geschnittener Flow ist überschaubar, ein schlecht geschnittener wird zum unwartbaren Monolithen.
Desktop Flows sind Power Automates Antwort auf Systeme, die keine API anbieten – die Realität in vielen mittelständischen IT-Landschaften mit gewachsenen ERP-, Branchen- oder Terminal-Anwendungen. Über Power Automate Desktop „bedient“ ein Software-Roboter die Oberfläche so, wie es ein Mensch täte: Felder ausfüllen, Schaltflächen klicken, Daten von Bildschirm zu Bildschirm tragen. Man unterscheidet attended RPA (läuft am Arbeitsplatz, vom Nutzer gestartet, als „Assistent“) und unattended RPA (läuft vollautomatisch auf einem Server, ohne Anwesenheit).
RPA ist mächtig, aber heikel. Weil die Automatisierung an der Oberfläche hängt, kann schon ein Update des Zielsystems, eine verschobene Schaltfläche oder ein geänderter Bildschirmaufbau den Roboter aus dem Tritt bringen. Deshalb gilt in unserer Beratungspraxis ein klarer Grundsatz: RPA ist eine Brücke, keine Dauerlösung. Wo eine API existiert oder nachgerüstet werden kann, ist der Cloud Flow vorzuziehen. RPA überbrückt die Zeit, bis ein Altsystem abgelöst oder mit einer Schnittstelle versehen ist.
Process Mining ist der oft übersehene Baustein. Bevor man automatisiert, sollte man wissen, was sich lohnt – und genau das liefert Process Mining: Es liest Ereignisprotokolle aus bestehenden Systemen, rekonstruiert daraus die real gelebten Prozesse (nicht die im Handbuch beschriebenen) und macht Engpässe, Schleifen und Abweichungen sichtbar. Für größere Häuser ist das ein wertvoller Kompass, um Automatisierungs-Budget dorthin zu lenken, wo es den größten Hebel hat.
Quer durch alle Bausteine zieht sich die Connector-Frage, und sie ist lizenzkritisch. Standard-Connectoren binden die M365-Welt an – SharePoint, Outlook, Teams, OneDrive, Excel Online – und sind in vielen Plänen enthalten. Premium-Connectoren öffnen die Tür zu Datenbanken (SQL Server), CRM- und ERP-Systemen (Salesforce, SAP, Dynamics), generischen HTTP-Aufrufen und Custom Connectors für eigene APIs. Sobald ein Flow auch nur einen einzigen Premium-Connector berührt, wird er lizenzpflichtig. Diese „ein Tropfen verdirbt den Eimer“-Logik ist der Kern fast aller Kosten-Überraschungen, auf die wir in Kapitel 06 zurückkommen.
Der Copilot in Power Automate ist ein echter Demokratisierungs-Schritt. Fachanwender, die nie eine Flow-Logik von Hand zusammengeklickt hätten, können nun beschreiben, was passieren soll, und erhalten einen Entwurf, den sie verfeinern. Das verschiebt Automatisierung aus der reinen IT in die Fachbereiche – mit allen Chancen und Risiken, die das mit sich bringt.
Die Grenze ist allerdings klar: Der Copilot beschleunigt das Bauen, ersetzt aber nicht das Denken. Ein schlecht durchdachter Prozess wird durch einen Prompt nicht besser – er entsteht nur schneller. In unserer Praxis sehen wir, dass Copilot-erstellte Flows hervorragend für klar umrissene Standardfälle taugen, bei Sonderfällen, Fehlerbehandlung und Wiederanlauf-Logik aber weiterhin Erfahrung gefragt ist. Wer den Copilot als Beschleuniger für Fachleute begreift und nicht als Ersatz für Prozessverständnis, holt das Beste heraus.
AI Builder bringt vortrainierte und anpassbare KI-Modelle in den Flow: Dokumentenverarbeitung (Formular- und Rechnungserkennung), Texterkennung, Objekterkennung, Vorhersagemodelle, Kategorisierung und – zunehmend – generative Bausteine über die Anbindung an Azure-OpenAI-Modelle. Für viele Mittelständler ist gerade die Belegerfassung der erste greifbare KI-Use-Case: Rechnungen automatisch auslesen, prüfen und in die Buchhaltung überführen.
Wichtig ist, dass AI Builder eine eigene Kostenlogik über Credits hat. KI-Verarbeitung wird nicht über die normale Flow-Lizenz abgedeckt, sondern verbraucht Kapazität, die separat lizenziert oder als Add-on gekauft wird. Bei niedrigem Volumen ist das unkritisch, bei der Massenverarbeitung von Dokumenten sollte der Credit-Verbrauch vorab kalkuliert werden – sonst wird aus dem günstigen Pilot ein teurer Dauerbetrieb.
Aus unserer Beratungspraxis lassen sich drei klare Gewinn-Szenarien für Power Automate benennen. Erstens, wenn Microsoft 365 die Hauptarbeitsumgebung ist: Die native Integration in SharePoint, Outlook, Teams und Dataverse erreicht kein Wettbewerber, und viele einfache Flows starten ohne zusätzliche Lizenz. Zweitens, wenn sowohl klassische App-Automatisierung als auch RPA gebraucht werden – Power Automate ist die einzige der hier verglichenen Plattformen, die beides unter einem Dach und einer Governance vereint. Drittens, wenn Governance, Datenresidenz und ein bestehender Auftragsverarbeitungsvertrag zählen: Wer Microsoft ohnehin als Auftragsverarbeiter im Haus hat, erweitert mit Power Automate eine bekannte Vertrags- und Compliance-Basis, statt einen neuen Anbieter zu prüfen.
Ebenso ehrlich gehört die Gegenseite benannt. Wer nur zwei, drei SaaS-Dienste außerhalb der Microsoft-Welt schnell verdrahten will, ist mit Zapier oft in Minuten am Ziel – die Einrichtung ist unschlagbar einfach. Wer hochkomplexe, verzweigte Szenarien mit vielen Transformationen bauen will, findet in Make ein mächtigeres visuelles Werkzeug. Wer technische Tiefe, eigenen Code, volle Datensouveränität und Self-Hosting braucht, ist mit n8n – quelloffen und auf eigenen Servern betreibbar – häufig besser bedient, gerade bei hohem Souveränitäts-Anspruch im DACH-Markt. Und wer eine große, geschäftskritische RPA-Flotte im Konzernmaßstab betreibt, wird in UiPath die reifere, robustere RPA-Plattform finden, deren Desktop-Automatisierung und Orchestrierung tiefer ausgebaut sind.
Die nüchterne Konsequenz: Power Automate ist kein Selbstzweck und keine Universal-Antwort. Es gewinnt aus der Logik des vorhandenen Stacks heraus – nicht, weil es in jeder einzelnen Disziplin Marktführer wäre. Wer keinen Microsoft-Bestand hat, sollte die Plattform-Wahl bewusst und herstellerneutral treffen.
Der typische Weg im Mittelstand beginnt klein: Ein Sachbearbeiter automatisiert die Ablage eingehender Mails, eine Abteilungsleiterin baut eine Urlaubsgenehmigung. Diese ersten Erfolge sind wertvoll, weil sie Akzeptanz schaffen – aber sie sind noch keine Strategie. Der Sprung vom Bastel-Flow zum tragenden Prozess gelingt erst, wenn Automatisierung als wartbare, dokumentierte und verantwortete Lösung behandelt wird: mit klarem Eigentümer, sauberer Fehlerbehandlung und einem Plan für den Fall, dass der Erbauer das Unternehmen verlässt.
Gerade Genehmigungen sind ein guter Startpunkt, weil sie sichtbar Mehrwert stiften und überwiegend mit Standard-Connectoren auskommen. Datenflüsse über Systemgrenzen hinweg sind wertvoll, berühren aber schnell Premium-Connectoren – hier lohnt der Blick auf die Lizenz, bevor der Flow produktiv geht. Und Teams-Automatisierung wirkt deshalb so stark, weil sie Prozesse genau dorthin holt, wo die Mitarbeitenden ohnehin den ganzen Tag sind.
Wir verzichten bewusst auf pauschale Einspar-Versprechen. Der Nutzen eines Flows hängt vom Volumen, von der Häufigkeit und von der Qualität des darunterliegenden Prozesses ab. Ein Genehmigungs-Flow, der zehnmal am Tag durchläuft, amortisiert sich anders als einer, der einmal im Monat anspringt. Realistisch ist: Power Automate nimmt repetitive Handarbeit ab, reduziert Übertragungsfehler und beschleunigt Durchlaufzeiten spürbar – aber nur, wenn der Prozess davor sauber geschnitten und die Lösung danach gepflegt wird. Ein automatisierter schlechter Prozess ist ein schneller schlechter Prozess, kein guter.
Der Kern der Lizenzlogik ist eine einzige Schwelle. Seeded-Rechte sind die in M365-Plänen mitgelieferten Power-Automate-Funktionen: Sie erlauben Cloud Flows mit Standard-Connectoren – also Automatisierung innerhalb der Microsoft-Welt. Das deckt viele Genehmigungs- und Ablage-Szenarien bereits ab und kostet keinen Cent extra. Sobald ein Flow jedoch einen Premium-Connector berührt – eine SQL-Datenbank, Salesforce, SAP, einen generischen HTTP-Aufruf oder einen Custom Connector – wird er lizenzpflichtig. Es genügt ein einziger Premium-Schritt im gesamten Flow, um die Lizenzpflicht auszulösen.
Bei der Premium-Lizenzierung gibt es zwei Modelle, die man bewusst gegeneinander abwägen sollte. Per User lizenziert eine Person für beliebig viele eigene Premium-Flows – ideal für einzelne Power-User, die viel bauen. Per Flow (bzw. Process) lizenziert einen bestimmten Flow unabhängig davon, wie viele Menschen ihn nutzen – ideal für einen breit genutzten Unternehmens-Flow, den hunderte Mitarbeitende anstoßen. Die Faustregel: Viele Flows pro Person sprechen für Per User, viele Personen pro Flow sprechen für Per Flow.
RPA hat eine eigene, oft teure Lizenzdimension. Attended RPA – der Roboter läuft am Arbeitsplatz, vom Nutzer gestartet – ist in der Premium-Per-User-Lizenz enthalten. Unattended RPA – der Roboter läuft vollautomatisch auf einem Server, ohne Anwesenheit – erfordert eine zusätzliche Lizenz pro Bot. Genau hier explodieren in der Praxis die Kosten: Wer mehrere unattended Bots rund um die Uhr betreiben will, zahlt pro Bot, und die Summe skaliert mit der Flotte. Eine RPA-Automatisierung, die im Pilot mit einem attended Bot günstig wirkte, kann im skalierten unattended Betrieb ein Vielfaches kosten.
Das wichtigste Governance-Werkzeug sind die Data-Loss-Prevention-Richtlinien. Sie ordnen jeden Connector einer von mehreren Gruppen zu – typischerweise „geschäftlich“, „nicht-geschäftlich“ und „blockiert“. Connectoren aus verschiedenen Gruppen dürfen nicht im selben Flow kombiniert werden. So lässt sich verhindern, dass ein Flow Geschäftsdaten aus SharePoint zieht und an einen privaten Cloud-Speicher oder einen unkontrollierten Social-Media-Dienst weitergibt. Ohne DLP-Richtlinien steht jeder Connector jedem zur Verfügung – und genau daraus entstehen die ungewollten Datenabflüsse.
Eng damit verbunden ist die Frage der Datenverbindungen: Jeder Flow nutzt Verbindungen zu Systemen, die mit konkreten Anmeldeinformationen hinterlegt sind. Ein Flow läuft mit den Rechten dieser Verbindungen – wer hier zu großzügig autorisiert, gibt einem automatisierten Ablauf mehr Zugriff, als er braucht. Das Least-Privilege-Prinzip ist deshalb auch bei Automatisierung der Maßstab: Eine Verbindung sollte nur auf die Systeme und Daten reichen, die der konkrete Flow tatsächlich benötigt.
Für die DSGVO ist die Datenresidenz zentral. Power Automate und Dataverse lassen sich in einer EU-Region betreiben, sodass die zugrundeliegenden Daten in europäischen Microsoft-Rechenzentren verbleiben. Die Mandanten-Region wird beim Aufsetzen festgelegt und sollte bewusst gewählt werden – sie nachträglich zu ändern ist aufwendig. Zu beachten bleibt: Microsoft ist ein US-Konzern und unterliegt dem US Cloud Act; die EU-Datenresidenz reduziert das Restrisiko deutlich, hebt es aber nicht vollständig auf. Für die meisten Mittelständler ist das Risiko bei bewusster Konfiguration akzeptabel; für besonders sensible Daten, Berufsgeheimnisträger oder KRITIS-nahe Bereiche gehört diese Frage in eine sorgfältige, fallbezogene Bewertung.
Das eigentliche Power-Automate-spezifische Risiko ist nicht der Anbieter – es ist die niedrige Einstiegshürde im eigenen Haus. Weil fast jeder Fachanwender, unterstützt vom Copilot, Flows bauen kann, entstehen schnell hunderte halb-offizielle Automatisierungen: gebaut von Einzelpersonen, dokumentiert nirgends, betrieben mit den persönlichen Anmeldedaten des Erbauers. Verlässt diese Person das Unternehmen, fällt der Flow aus – oder läuft mit verwaisten Rechten weiter. Genau das nennen wir Citizen-Developer-Wildwuchs, und es ist in der Praxis das häufigste Governance-Problem.
Die Antwort ist keine Verbotskultur, sondern strukturierte Befähigung: Umgebungen sauftrennen, DLP-Richtlinien zentral setzen, eine Default-Umgebung mit klaren Leitplanken bereitstellen, kritische Flows in eine verantwortete Produktions-Umgebung überführen und Eigentümerschaft sowie Service-Konten für betriebskritische Automatisierung verbindlich machen. So bleibt die Demokratisierung erhalten, ohne dass das Unternehmen die Kontrolle über seine Datenflüsse verliert. Das ist der Brückenschlag zur strukturierten Einführung in Kapitel 09.
Die enge Verzahnung mit Microsoft 365 ist Power Automates Alleinstellungsmerkmal. Kein Wettbewerber erreicht diese Selbstverständlichkeit beim Zugriff auf SharePoint-Listen, Outlook-Postfächer, Teams-Kanäle und Dataverse-Tabellen. Für ein Haus, das ohnehin auf Microsoft setzt, bedeutet das: weniger Reibung, weniger Vertragsaufwand, schnellere erste Erfolge. Dieselbe Integration ist aber auch eine Bindung. Wer Power Automate produktiv nutzt, vertieft seine Abhängigkeit vom Microsoft-Ökosystem – Daten in Dataverse, Logik in Flows, Oberflächen in Power Apps. Ein späterer Wechsel ist möglich, aber nicht trivial. Diese strategische Dimension gehört in die Plattform-Entscheidung.
Die zweite Wahrheit: Power Automate ist mächtig, aber nicht einfach zu beherrschen, sobald man die ersten Standard-Flows hinter sich lässt. Die Lizenzlogik mit ihren Seeded-, Per-User-, Per-Flow-, Process- und Credit-Dimensionen ist erklärungsbedürftig und ändert sich regelmäßig. RPA bringt Wartungsaufwand mit, weil jede Änderung an einem Zielsystem die Automatisierung brechen kann. Und ohne Governance kippt die niedrige Einstiegshürde in unkontrollierten Wildwuchs. Power Automate belohnt Häuser, die Automatisierung als verantwortete Disziplin betreiben – und bestraft die, die es als Selbstläufer missverstehen. Wer diese Reibung einkalkuliert und mit Struktur beantwortet, bekommt eine außergewöhnlich leistungsfähige Plattform.
Der wichtigste Erfolgsfaktor jenseits der Technik ist ein Center of Excellence – eine kleine, dauerhaft verantwortliche Struktur, die der Automatisierung im Haus einen Rahmen gibt. Das CoE ist nicht der Engpass, durch den jeder Flow muss, sondern der Enabler: Es stellt Vorlagen, Konventionen und Schulungen bereit, betreut die DLP- und Umgebungs-Governance, prüft betriebskritische Flows vor dem Produktivgang und bündelt das Lizenz-Know-how. Microsoft stellt dafür ein eigenes CoE-Starter-Kit bereit, das Transparenz über alle Flows, Verbindungen und Maker im Mandanten schafft – ein wertvolles Werkzeug gegen den Wildwuchs.
In unserer Praxis ist das CoE das, was den Unterschied zwischen einer Sammlung zufälliger Bastel-Flows und einer tragfähigen Automatisierungs-Plattform ausmacht. Es muss nicht groß sein – oft reichen ein bis zwei verantwortliche Personen mit klarem Mandat und Rückhalt der Leitung. Entscheidend ist, dass es überhaupt existiert, bevor die Zahl der Flows in die Hunderte geht.
Eine erste produktive Automatisierung ist je nach Prozess in Wochen erreichbar – das ist die gute Nachricht und der Grund, warum Power Automate so attraktiv ist. Eine tragfähige Plattform mit Governance, CoE und mehreren produktiven Prozessen ist hingegen ein Programm über Monate. Wer „nur Lizenzen kauft“ und sofort breit ausrollt, riskiert Wildwuchs, ungewollte Datenflüsse und schlechte Wartbarkeit. Wer dagegen klein und sauber startet, das Fundament früh legt und über ein CoE skaliert, baut eine Automatisierungs-Fähigkeit auf, die mit dem Unternehmen wächst. Die Reihenfolge – erst Governance und Lizenz-Strategie, dann Breite – ist dabei kein bürokratischer Umweg, sondern der direkte Weg zu einem belastbaren Ergebnis.
