Power Automate ist keine "KI": es ist der Klempner von Microsoft 365
Bevor du entscheidest, ob Power Automate dein Werkzeug ist, hilft es zu wissen, was es wirklich ist, denn der Name täuscht. Power Automate ist der Automatisierungsbaustein von Microsofts Power Platform: es bewegt Daten zwischen deinen Apps, löst Benachrichtigungen aus, startet Freigaben und führt Flows aus, wenn etwas passiert. Geboren als feste Regeln —kommt eine E-Mail mit Anhang, leg sie in SharePoint ab—, wurde ihm KI drangeschraubt (Copilot zum Bauen des Flows, AI Builder zum Lesen eines Dokuments). Aber seine DNA bleibt die einer deterministischen Flow-Engine, an Office geklebt, nicht die eines Systems, das mit Urteilskraft entscheidet. Beides zu verwechseln ist der erste teure Fehler.
Deshalb geht dieser Leitfaden nicht um "wie automatisiere ich Microsoft 365" —das ist ein anderes Gespräch, eine KI-Schicht über deine Suite zu bauen, das behandeln wir in KI für Microsoft 365—. Er geht um eine frühere Entscheidung: wann Power Automate das richtige Werkzeug für dein Unternehmen ist und wann du es zu etwas zwingst, wofür es Besseres gibt. Es ist dieselbe Übung wie ein Automatisierungswerkzeug wählen, angewandt auf den Fall dessen, der schon in Microsoft lebt.
Wann Power Automate die offensichtliche Antwort ist
Es gibt drei Situationen, in denen Power Automate fast ohne Diskussion gewinnt, und alle drei hängen davon ab, wo dein Unternehmen schon lebt, nicht davon, wie schlau das Werkzeug ist. Erstens: du steckst bis zum Hals in Microsoft 365. Wenn deine Mail Outlook ist, deine Dokumente in SharePoint und Teams leben, deine Leute in Excel arbeiten und deine Identität von Entra (dem alten Azure AD) verwaltet wird, spricht Power Automate diese Sprache nativ. Kein Connector zu warten, keine Berechtigung zu erkämpfen: das Werkzeug ist schon in deinem Perimeter und dein Admin kontrolliert es schon.
Zweitens: Freigabe-Flows. Urlaub, Spesen, Rechnungsprüfung, ein Onboarding, das drei Freigaben braucht. Power Automate macht das besonders gut —Freigabekarten in Teams und Outlook, mit einer Spur, wer was wann freigegeben hat— und das ist der Grund, warum viele es einführen, ohne sonst etwas entschieden zu haben. Drittens: RPA über alte Systeme ohne API. Wenn du ein fünfzehn Jahre altes ERP hast oder eine Desktop-App, durch die man sich klicken muss, automatisieren Power Automates Desktop Flows diese Interaktion wie ein Roboter, der den Bildschirm nutzt. Dort tritt es gegen UiPath und Automation Anywhere an, nicht gegen Zapier.
Das Lizenzmodell, das keiner ansieht, bis die Rechnung kommt
Hier bekommt fast jeder den Schreck. Power Automate kommt "inklusive" in vielen Microsoft-365-Plänen, und dieses Wort —inklusive— ist die Falle. Gratis kommen die Flows, die nur Standard-Office-Apps mit Basis-Connectoren berühren. Sobald ein Flow die Linie der Premium-Connectoren überschreitet (SQL Server, Salesforce, SAP, Dataverse, HTTP, eigene Connectoren), ist er nicht mehr gratis und verlangt eine bezahlte Lizenz. Und diese Linie überschreitest du fast immer, weil echte Arbeit selten in Office bleibt.
Das Lizenzmodell hat, Stand 2026, drei Hauptformen, und falsch zu wählen kostet Geld beim Skalieren. Die Lizenz pro Nutzer lässt eine Person alle Flows laufen, die sie will; sie lohnt sich, wenn wenige Nutzer Premium-Fähigkeiten brauchen. Die Lizenz pro Flow (oder pro Prozess) zahlt einen bestimmten Flow, egal wie viele ihn auslösen; sie gewinnt, wenn ein Flow von vielen genutzt wird. Und die unbeaufsichtigte RPA —ein Bot, der allein läuft, ohne jemanden davor— wird separat lizenziert, pro Bot, und ist mit Abstand die teuerste Position. Dazu kommt das On-Premise-Data-Gateway, wenn ein Cloud-Flow Daten berühren soll, die auf deinem Server leben: eine Premium-Fähigkeit, kein Gratis-Extra.
| Modell | Was es zahlt | Wann es sich lohnt |
|---|---|---|
| Pro Nutzer | Dass eine Person unbegrenzt Premium-Flows fährt | Wenige Nutzer mit Premium-Bedarf |
| Pro Flow / Prozess | Ein bestimmter Flow, egal wer ihn auslöst | Ein Flow, den viele nutzen |
| Unbeaufsichtigte RPA | Ein Bot, der allein läuft, niemand davor | Legacy im Volumen robotisieren (teure Position) |
| Data Gateway | Brücke zu On-Premise-Daten aus der Cloud | Flows, die deinen Server berühren, nicht nur Office |
Die Disziplin ist dieselbe wie beim ROI einer Automatisierung berechnen: schau nicht auf den Einstiegspreis —das "hast du schon mit deinem 365"—, rechne es zum Volumen und Flow-Typ, den du binnen eines Jahres fährst, Premium-Connectoren und RPA inklusive, wenn du sie brauchst. Ein "inklusive", das anspringt, sobald du ein echtes System berührst, ist nicht gratis; es ist eine Kostenentscheidung, die du später zahlst.
Cloud Flows und Desktop Flows: zwei Werkzeuge unter einem Namen
Ein Detail, das Neulinge verwirrt: unter dem Namen "Power Automate" leben zwei verschiedene Produkte. Die Cloud Flows laufen in Microsofts Cloud und verbinden Apps per API —das tritt gegen Make, n8n oder Zapier an, und um zwischen diesen beiden Familien zu wählen, gilt dasselbe Kriterium wie Make vs n8n—. Die Desktop Flows sind RPA: ein auf einer Maschine installierter Roboter, der Desktop-Apps steuert, indem er einen Menschen imitiert —öffnet den Bildschirm, klickt, tippt, kopiert—. Sie dienen genau dem Gegenteil: Systemen ohne API, mit denen man nur über die Oberfläche sprechen kann.
Der Unterschied zählt beim Entscheiden, denn jeder löst ein Problem und jeder wird anders bezahlt. Wenn deine Automatisierung moderne Apps mit API verbindet, willst du Cloud Flows und trittst auf dem üblichen No-Code-Terrain an. Wenn deine Automatisierung sich mit einem alten Programm ohne API herumschlagen muss, willst du Desktop Flows und bist im RPA-Terrain, das naturgemäß fragiler ist: eine Änderung am Bildschirm des Legacy-Systems bricht den Roboter. Genau diese Fragilität macht die Wartung der Automatisierungen zur Position, die keiner budgetiert —und in RPA wiegt sie doppelt.
Wo Power Automate zu kurz kommt (und was du dann ansiehst)
Power Automate ist eine exzellente Flow-Engine, aber es hat zwei Decken, die man sehen sollte, bevor man es heiratet. Die erste ist die Urteilsdecke: von Design her führt es Regeln aus, es entscheidet nicht über mehrdeutigen Kontext. Copilot hilft dir, den Flow zu bauen, und AI Builder kann ein Dokument mit bekanntem Format lesen, aber wenn die Arbeit verlangt, freien Text zu lesen, die Absicht einer Mail zu verstehen oder abzugleichen, was zwischen drei Systemen nicht passt, bleibt Power Automate am Rand stehen. Dort brauchst du keinen längeren Flow: du brauchst eine Entscheidungsschicht —Sprachmodelle mit der Logik drum herum— obendrauf, worum es bei mit KI automatisieren gegenüber klassischer Automatisierung wirklich geht.
Die zweite ist die Decke des geschlossenen Hauses: Power Automate gehört Microsoft und glänzt in Microsoft. Sobald deine Operation halb draußen lebt —dein CRM ist HubSpot, dein Produkt läuft auf Google Cloud, dein Team arbeitet in Notion und Slack— zwingst du das Werkzeug über Grenzen, an denen andere Optionen natürlicher und günstiger sind. Nicht, dass es nicht könnte; sondern du hörst auf, seinen einen großen Vorteil (native Office-Integration) zu nutzen, und behältst nur seine Kosten. Wenn der Flow mit Systemen von draußen reden muss, ist das eigentliche Problem nicht mehr das Werkzeug, sondern KI mit deinen Systemen zu integrieren, ohne dass es bricht, wenn eines sich von allein ändert.
| Deine Lage | Power Automate | Auch ansehen |
|---|---|---|
| Alles in Microsoft 365, Office-Flows | Natürliche Passung | — |
| Freigaben und interne Alerts | Schwer zu schlagen | — |
| Legacy ohne API (RPA) | Desktop Flows, eigenes Terrain | UiPath, Automation Anywhere |
| Moderne Apps mit API verbinden | Cloud Flows, funktioniert | Make, n8n, Zapier |
| Entscheidung über Text/Kontext | Bleibt am Rand | Maßgeschneiderte KI-Schicht obendrauf |
| Stack halb außerhalb von Microsoft | Du zwingst das Werkzeug | Anbieterneutrale Optionen |
Also, Power Automate oder nicht?
Die ehrliche Version: ja, wenn dein Unternehmen in Microsoft 365 lebt, deine Automatisierungen Office-Daten bewegen, Freigaben starten oder ein Legacy-System robotisieren, und du das Lizenzmodell vor dem Skalieren klar hast. Mit Vorbehalten, wenn dein Stack halb draußen ist oder die Arbeit echte Urteilskraft verlangt: dort kann Power Automate ein Baustein sein —der Arm, der in Office ausführt— aber nicht das ganze System, und die grundlegende Entscheidung ist wieder welche Prozesse zu automatisieren und mit welcher Passung, nicht welches Werkzeug zu kaufen. Die Marke ist die letzte Entscheidung, nicht die erste.