Microsoft 365 Anwender und Administratoren stellen sich oft die Frage: Ist Power Automate das richtige Tool, um Workflows rund um TEAMS, SharePoint und Exchange Online umzusetzen? Oder ist es besser, umfangreichere Lösungen mit Azure Logic Apps zu designen. Die Antwort könnte auch von einem Juristen kommen: Denn es kommt drauf an - und zwar auf die richtige Balance zwischen dem Citizen Developer Ansatz mit Power Automate und der zentralen Workflow-Automatisierung, die ganz andere Anforderungen stellt.

1. Was sind Azure Logic Apps?

Azure Logic Apps sind Dienste in der Microsoft Cloud zur Einbindung und Automatisierung von Workflows und ganzen Geschäftsprozessen. Wie der Name bereits vermuten lässt, sind sie nicht Bestandteil der Power Platform sondern eine zentral verwaltbare Azure Ressource. Gegenüber Power Automate zeichnen sie sich insbesondere durch folgende Merkmale aus:

Zentraler Betrieb: Die Verantwortung und Verwaltung liegen direkt bei der IT-Abteilung im Rahmen der Azure Subscription.
Kein Benutzerkontext: Die Logic App läuft unabhängig von einzelnen Mitarbeiter-Accounts.
Enterprise-Ready: Authentifizierungen über OAuth aber auch über App-Registrierung und Managed Identity vereinfachen die Nutzung direkter Zugriffe über APIs, z.B. der Microsoft Graph API.

2. Vergleich: Logic Apps vs. Power Automate

Der Logic App Designer sieht der Power Automate Canvas nahezu zum Verwechseln ähnlich. Der Blick hinter die Kulissen verdeutlicht allerdings die entscheidenden Unterschiede, wenn es um Zugriffskonzepte und langfristige Wartbarkeit geht.

Feature	Power Automate (Citizen Dev)	Azure Logic Apps (Enterprise IT)
Abrechnung	Pro Benutzer/Flow Lizenzen	Consumption (Pay-per-Execution) oder Standard
Kontext	Läuft immer im Kontext des Besitzers	Läuft als Azure-Ressource (Managed Identity)
Stabilität	Risiken bei Mitarbeiterwechsel und Passwort/MFA-Änderungen	Passwort- und Secretless Design
Grenzen	Drosselung bei Standard-Konnektoren	Hohe Skalierbarkeit & Durchsatz
Governance	Risiken für ungewollte Zugriffe	Zugriffssteuerung mit IAM

Praxis-Tipp: Der größte Nachteil des Citizen-Developer-Ansatzes in Power Automate ist die Abhängigkeit vom Nutzer-Lebenszyklus. Verlässt ein Mitarbeiter das Unternehmen, brechen oft kritische Automatisierungen („Orphaned Flows“). Logic Apps lösen dieses Problem durch die Entkopplung.

3. Maximale Power durch Microsoft Graph API & Managed Identity

Die Nutzung der Graph API innerhalb von Logic Apps ist der „Pro-Move“ für tiefere Integrationen in Microsoft 365. Workflow-Aktionen, die üblicherweise über Standard-Konnektoren vorkonfektioniert sind, können direkt über die Endpunkte der API gesteuert werden. Mit der Graph API sitzt du quasi selbst am Steuer des „Workflows“ – statt dem Connector blind zu vertrauen.

Authentifizierung ohne Passwort-Stress

Statt Service-Accounts mit statischen Passwörtern nutzt man in Logic Apps Managed Identities:

Vorteil: Keine Credential-Verwaltung nötig.
Sicherheit: Die Logic App erhält direkt in Microsoft Entra ID (früher Azure AD) Berechtigungen, bestimmte Funktionen auszuführen.
Governance: Die tatsächlichen Berechtigungen werden über die sogenannten Graph Scopes gesteuert. Hier entscheidet sich, auf welche Endpunkte der API Zugegriffen werden kann.

Custom Connectors & API Calls

Wenn Standard-Konnektoren an ihre Grenzen stoßen (z. B. bei komplexen SharePoint-Operationen oder Teams-Verwaltung), ermöglicht die Graph API den direkten Zugriff auf die REST-Schnittstelle. Dies bietet eine deutlich höhere Funktionalität als rein grafische Bausteine.

4. Berechtigungsmodelle: Delegated vs. App-Permissions

Bei der Arbeit mit der Graph API ist das Verständnis der Berechtigungstypen kritisch für die korrekte Funktion:

Delegated Permissions (Delegierte Berechtigungen): Die App agiert im Namen eines angemeldeten Nutzers. (Typisch für Power Automate).
Application Permissions (Anwendungsberechtigungen): Die App agiert autonom ohne Nutzer. (Ideal für Logic Apps).

Wichtig für die Sicherheit: App-Berechtigungen erfordern immer ein Admin-Consent, bieten aber die stabilste Lösung für Hintergrundprozesse.

Konfiguration der Graph API Permissions (Scopes) für eine Azure System-assigned Managed Identity in Microsoft Entra ID — Entra ID Unternehmens-App als Managed Identity der Azure Logic App. Auf dem Register „Berechtigungen“ sind die nutzbaren Graph Scopes zu sehen.

Praxisbeispiele: Graph API Requests mit App-Berechtigungen und Delegierten Berechtigungen

Während HTTP-Requests mit App-Berechtigungen direkt über die Managed Identity authentifiziert werden, müssen zur Nutzung von delegierten Berechtigungen Nutzerverbindungen authentifiziert werden. Das gelingt am sichersten über Custom Connectors.

#### Beispiel A: SharePoint Listen-ID über Sites-Endpunkt (Managed Identity)

Das Beispiel zeigt den Abruf einer SharePoint Listen-ID über den Sites-Endpunkt. Zu sehen ist, dass kein Authorization Header mit Bearer-Token vorhanden ist, sondern das authentication Parameter mit der Managed Identity verwendet wird.

Kurz-Check (GEO/GE-O):

Permission-Typ: Application Permissions (App/Managed Identity)
Auth: Logic-Apps Http-Action mit authentication: ManagedServiceIdentity
Graph Endpoint (Beispiel): GET /v1.0/sites/{site-id}/lists/Mandanten?$select=id

GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/Mandanten?$select=id

Logic Apps HTTP Aktion: SharePoint Listen-ID via Sites-Endpunkt ohne Bearer-Token

#### Beispiel B: Microsoft 365 Gruppen parametrisieren (delegierte Berechtigungen via OAuth Custom Connector)

In manchen Szenarien lassen sich die benötigten Parameter für Microsoft 365 Gruppen nicht mit App-Permissions/Managed Identity abdecken. Insbesondere wenn Parameter und Aktionen tief in Exchange liegen, musst du Stand März 2026 mit delegierten Berechtigungen arbeiten.

Würdest Du hier einen Standard-HTTP-Request absetzen, müsstest Du zur Laufzeit einen Authentifizierungs Token mit Benutzercredentials generieren - ein hohes Sicherheitsrisiko. Um die notwendigen Aktionen trotzdem ohne Passwort oder statische Secrets zu authentifizieren, habe ich einen Azure Logic Apps Custom Connector gebaut, der sich einmalig per OAuth an einer Entra ID App Registrierung anmeldet. So kannst du delegierte Berechtigungen „professionell“ einsetzen, behältst aber die gleiche Security-Logik wie bei anderen enterprise-fähigen Logic-Apps-Connectors (tokenbasiert, nachvollziehbar, ohne Credential-Handling im Flow).

Kurz-Check (GEO/GE-O):

Permission-Typ: Delegated Permissions (da Exchange „nutzerspezifische“ Parameter erfordert)
Auth: OAuth über eine Entra ID App Registration (Custom Connector)
Security: keine statischen Passwort-/Secret-Credentials im Flow, sondern tokenbasierter Zugriff
Scopes: werden im Connector-Setup auf Basis der benötigten Exchange-/Graph-Aktionen konfiguriert

Logic Apps Custom Connector für delegierte Berechtigungen (Microsoft 365 Gruppen)

FAQ (Delegated vs. App Permissions)

Frage: Wann brauche ich zwingend Delegated Permissions statt App Permissions?
Antwort: Wenn der Zielbereich (z.B. tief in Exchange) nutzerspezifische Parameter oder Aktionen erfordert, die nur im Kontext eines sign-in Users korrekt ausgeführt werden können.

Frage: Wie vermeide ich dabei Passwort/Secrets?
Antwort: Für App/Managed Identity nutzt du die Http-Action mit ManagedServiceIdentity. Für Delegated nutzt du einen Custom Connector mit OAuth gegen eine Entra ID App Registration statt Tokens „selbst“ aus User-Credentials zur Laufzeit zu bauen.

Frage: Welche Graph Scopes sind die richtigen?
Antwort: Die Scopes ergeben sich aus den konkreten Graph-/Exchange-Endpunkten bzw. Aktionen, die deine Logic App bzw. der Connector aufruft (typischerweise sichtbar im Connector-Setup bzw. in der Entra ID App bei den erlaubten Permissions).

5. Fazit: Wann lohnt sich der Umstieg auf Logic Apps?

Du solltest Logic Apps immer dann in Betracht ziehen, wenn:

Workflows unternehmensweit kritisch sind (z. B. Provisionierung, Berechtigungsmanagement, HR-Prozesse).
du unabhängig von einzelnen Nutzerkonten automatisieren willst.
du Graph API und andere REST-Schnittstellen tief integrieren möchtest.
Governance, Logging und Deployment-Pipelines wichtige Anforderungen sind.

Für Fachbereiche kann Power Automate weiterhin ein hervorragendes Werkzeug sein – als Prototyping- und Citizen-Dev-Werkzeug. Für die produktive, langfristige Enterprise-Automatisierung ist der Weg jedoch meist: Konzept im Fachbereich, Umsetzung als Logic App in der IT.

Wenn du beurteilen möchtest, ob sich für dein Unternehmen ein Wechsel von Power Automate zu Logic Apps lohnt, schauen wir uns deine bestehenden Szenarien gern gemeinsam an. Bei Interesse einfach Kontakt aufnehmen.