Ein Auftrag geht ein. Die Bestellung landet im ERP-System, eine E-Mail geht raus, ein Eintrag in der SharePoint-Liste wird angelegt, und das zuständige Team bekommt eine Teams-Nachricht. Klingt nach einem halben Arbeitstag manueller Weiterleitung — oder nach einem Power-Automate-Flow, der in zwanzig Minuten erledigt ist.
Das funktioniert — solange alle beteiligten Systeme Konnektoren haben, die Power Automate versteht. In der Praxis ist das öfter eine offene Frage, als man zunächst annimmt. Neben SharePoint, Teams und Outlook gibt es im Mittelstand eine Vielzahl von Branchenlösungen, Eigenentwicklungen und Legacy-Systemen, die Power Automate von Haus aus nicht kennt.
Genau hier kommen Custom Connectors ins Spiel. Dieser Post erklärt, wie das Connector-Ökosystem von Power Automate aufgebaut ist, wann welcher Ansatz sinnvoll ist — und was Custom Connectors wirklich leisten.
Das Connector-Ökosystem: drei Ebenen
Power Automate unterscheidet zwischen drei Klassen von Konnektoren, die sich in Funktionsumfang, Lizenzanforderung und Aufwand unterscheiden.
Standardkonnektoren sind im M365-Abonnement enthalten und decken die meisten Microsoft-eigenen Dienste ab: SharePoint, Teams, Outlook, OneDrive, Excel, Planner, Forms, OneNote. Dazu kommen zahlreiche Drittsystem-Konnektoren wie Twitter, Dropbox, Google Drive oder Mailchimp — ebenfalls ohne Aufpreis nutzbar.
Premiumkonnektoren erfordern eine separate Power Automate-Lizenz (aktuell ab ca. 15 EUR pro Nutzer und Monat). In diese Kategorie fallen Konnektoren für SQL Server, Dataverse, SAP, Salesforce, ServiceNow, Adobe Sign und viele weitere Enterprise-Systeme. Auch der generische HTTP-Konnektor — mit dem sich beliebige REST-APIs ansprechen lassen — ist ein Premiumkonnektor.
Custom Connectors sind selbst entwickelte Konnektoren für Systeme, die weder als Standard- noch als Premiumkonnektor vorhanden sind. Sie basieren auf einer OpenAPI-Beschreibung der Ziel-API und werden im Power-Platform-Admin-Center des eigenen Tenants registriert. Ihre Nutzung erfordert ebenfalls eine Premiumlizenz.
Daneben gibt es noch On-Premises-Datengateways — für Systeme, die nicht über das Internet erreichbar sind. Das Gateway fungiert als Brücke zwischen dem Cloud-Service Power Automate und einer Anwendung im Firmennetz. Auch das ist ein Thema für sich, hängt aber eng mit dem Konnektor-Thema zusammen.
Wann reichen Standardkonnektoren aus?
Für viele mittelständische Automatisierungsanforderungen reichen die Standardkonnektoren vollständig aus. Die Faustregel: Wenn alle beteiligten Systeme im Microsoft-365-Ökosystem liegen — SharePoint, Teams, Outlook, Excel, Planner — sind Standardkonnektoren die erste Wahl.
Typische Szenarien, die ohne Premiumlizenz funktionieren:
- Neue SharePoint-Listeneinträge lösen eine Teams-Benachrichtigung aus
- Formulareingaben aus Microsoft Forms landen strukturiert in einer SharePoint-Liste
- Genehmigungs-Workflows mit SharePoint und Outlook
- Tägliche Excel-Berichte, die automatisch per E-Mail versandt werden
- Synchronisation von Planner-Aufgaben mit SharePoint-Listen
Bevor man in Premiumlizenzen oder Custom-Connector-Entwicklung investiert, lohnt sich ein sorgfältiger Blick, ob das Ziel nicht mit Standardmitteln erreichbar ist.
Wann wird ein Custom Connector nötig?
Ein Custom Connector wird dann relevant, wenn ein System angebunden werden soll, das:
- keinen nativen Power-Automate-Konnektor hat
- über eine REST- oder SOAP-API verfügt
- für Automatisierungen im eigenen Tenant dauerhaft gebraucht wird
Typische Kandidaten im Mittelstand:
- Branchenspezifische ERP-Systeme ohne native Anbindung (ProAlpha, Sage, Diamant, Navision-Altversionen)
- Interne Webservices oder APIs, die von der eigenen IT entwickelt wurden
- Spezialisierte Fachverfahren in Energieversorgung, Logistik oder Fertigung
- SaaS-Produkte, für die Microsoft noch keinen fertigen Konnektor anbietet
- Externe öffentliche APIs (Adressvalidierung, Postdienste, Wetterdaten, Geodienste)
Der Unterschied zum generischen HTTP-Konnektor: Der HTTP-Konnektor funktioniert für einzelne API-Aufrufe, die man einmalig konfiguriert. Ein Custom Connector abstrahiert die API dahinter — er stellt Aktionen und Trigger als wiederverwendbare Bausteine zur Verfügung, die andere Flow-Ersteller im Tenant nutzen können, ohne die API-Details kennen zu müssen.
Was ein Custom Connector technisch erfordert
Damit ein Custom Connector entwickelt und genutzt werden kann, müssen einige Voraussetzungen erfüllt sein.
Das Zielsystem braucht eine API. Power Automate kommuniziert mit Custom Connectors über REST (bevorzugt) oder SOAP. Systeme ohne API-Schnittstelle können nicht direkt angebunden werden — hier wäre ein Zwischenschritt nötig, etwa eine Azure Function, die als Adapter fungiert.
Die API muss über HTTPS erreichbar sein. Rein interne Systeme ohne HTTPS-Endpunkt sind direkt nicht anbindbar. Lösung: On-Premises-Datengateway oder ein Reverse Proxy.
Authentifizierung muss unterstützt werden. Custom Connectors unterstützen mehrere Authentifizierungsarten: API-Key, Basic Auth, OAuth 2.0 und Windows-Authentifizierung. Welche davon die Ziel-API anbietet, bestimmt, welches Verfahren konfiguriert wird.
Eine OpenAPI-Beschreibung vereinfacht die Entwicklung erheblich. OpenAPI (früher Swagger) ist ein standardisiertes Format zur Beschreibung von REST-APIs. Wenn das Zielsystem bereits eine OpenAPI-Spezifikation liefert, lässt sich der Custom Connector daraus direkt importieren. Ansonsten muss die Beschreibung manuell erstellt werden.
Aufbau eines Custom Connectors: der Ablauf
Der Entwicklungsprozess folgt einem überschaubaren Muster:
- API analysieren — Welche Endpunkte existieren? Welche Parameter werden erwartet? Welche Antworten zurückgegeben?
- OpenAPI-Beschreibung erstellen — Entweder aus vorhandener Dokumentation exportiert oder manuell verfasst. Tools wie Swagger Editor helfen dabei.
- Connector im Power Platform Admin Center anlegen — Import der OpenAPI-Datei oder manuelle Konfiguration der Aktionen und Trigger.
- Authentifizierung konfigurieren — API-Key, OAuth oder eine der anderen unterstützten Methoden einrichten.
- Testen — Der Connector-Editor in Power Automate enthält eine integrierte Testoberfläche, um Anfragen direkt abzuschicken und Antworten zu prüfen.
- Freigabe im Tenant — Nach erfolgreichem Test kann der Connector für alle Nutzer im Tenant freigegeben werden.
Dieser Prozess ist kein Entwicklungsprojekt im klassischen Sinne — wer REST-APIs kennt und mit JSON umgehen kann, kommt für unkomplizierte APIs in wenigen Stunden zum Ziel. Komplexere Systeme mit vielen Endpunkten, komplizierter Authentifizierung oder proprietären Datenformaten erfordern mehr Aufwand.
Lizenzierung: Was Custom Connectors kosten
Ein häufig unterschätzter Punkt: Nicht nur wer den Custom Connector entwickelt, braucht eine Premiumlizenz — sondern jeder Nutzer, dessen Flow diesen Connector verwendet.
Das bedeutet in der Praxis: Wenn ein Flow mit einem Custom Connector von zwanzig Mitarbeitenden ausgelöst wird, benötigen alle zwanzig eine Power-Automate-Premiumlizenz. Bei rein automatisierten Flows (ohne menschliche Auslöser) reicht eine lizenzierte Verbindung aus — der Kontext entscheidet.
Lizenzmodelle (Stand 2026):
- Power Automate Premium (nutzerbasiert): ca. 15 EUR/Nutzer/Monat — für Flows, die ein bestimmter Nutzer auslöst
- Power Automate Process (prozessbasiert): ca. 150 EUR/Prozess/Monat — für vollautomatisierte Flows ohne Nutzerbindung
Für Szenarien mit vielen Nutzern und wenigen automatisierten Prozessen kann das Prozessmodell wirtschaftlicher sein. Für breite Nutzerbasis lohnt sich der Vergleich.
Praktische Grenzen kennen
Custom Connectors sind kein Allheilmittel. Einige Einschränkungen, die in der Praxis relevant werden:
Kein Echtzeit-Polling. Trigger in Custom Connectors funktionieren über Polling — Power Automate fragt das Zielsystem in regelmäßigen Abständen ab. Echte Webhooks (bei denen das Zielsystem Power Automate aktiv benachrichtigt) sind nur möglich, wenn die Ziel-API das unterstützt und entsprechend konfiguriert wird.
Kein direkter Datenbankzugriff. Custom Connectors sprechen immer gegen eine API-Schicht — nicht direkt gegen eine Datenbank. Wer direkten SQL-Zugriff braucht, nutzt den SQL-Server-Premiumkonnektor.
Tenant-Bindung. Custom Connectors sind im eigenen Tenant registriert und nicht ohne Weiteres in andere Tenants übertragbar. Für Lösungen, die an Kunden weitergegeben werden sollen, gibt es zertifizierte Konnektoren bei Microsoft — ein anderer, aufwändigerer Prozess.
Wartungsaufwand. Wenn sich die Ziel-API ändert (neue Versionen, geänderte Parameter), muss der Custom Connector entsprechend aktualisiert werden. Ohne Versionsstrategie kann das zu überraschenden Flows-Ausfällen führen.
Fazit
Das Connector-Ökosystem von Power Automate ist gut durchdacht: Standardkonnektoren für den M365-Alltag, Premiumkonnektoren für gängige Enterprise-Systeme, Custom Connectors für alles, was dazwischen liegt oder darüber hinausgeht.
Für mittelständische Unternehmen ist die wichtigste Frage nicht „Wie baue ich einen Custom Connector?“, sondern „Brauche ich wirklich einen?“ Viele Integrationsszenarien lassen sich mit dem generischen HTTP-Konnektor oder einem vorhandenen Premiumkonnektor lösen — schneller und mit weniger Wartungsaufwand als ein selbst entwickelter Connector.
Wo Custom Connectors sinnvoll sind: wenn ein System dauerhaft in mehrere Flows eingebunden wird, wenn andere Teams diese Integration nutzen sollen, ohne API-Details zu kennen, oder wenn die Ziel-API so spezifisch ist, dass kein fertiger Konnektor existiert. In diesen Fällen zahlt sich die Investition in einen sauber entwickelten Custom Connector schnell aus.
