Der Flow läuft. Der Prozess trotzdem nicht: Ownership und ALM für Power Automate

Ein Cloud Flow kann technisch fehlerfrei sein und trotzdem ein Betriebsrisiko darstellen. Das fällt häufig erst auf, wenn sein Ersteller das Unternehmen verlässt, ein Kennwort geändert wird oder ein Release im Zielsystem nicht aktiviert werden kann.

Die Ursache ist selten „der eine fehlende Owner“. Ein produktiver Flow hängt von mehreren getrennten Bausteinen ab: Owner, Co-Owner, Run-only-Berechtigungen, Connections, Connection References, Credentials, Lizenzierung, Solution, Environment und Deployment-Pipeline. Wer diese Begriffe vermischt, baut eine Übergabe, die nur auf dem Papier funktioniert.

Die Leitthese lautet deshalb:

Ein Flow bleibt nur dann betreibbar, wenn Ownership, Berechtigungen, Authentifizierung, Lizenzierung und ALM getrennt kontrolliert und gemeinsam getestet werden.

Dieser Beitrag liefert dafür ein wiederverwendbares Flow Operations & ALM Runbook samt konkretem Testplan. Es dokumentiert keine bereits ausgeführten Kundentests und keine gemessenen Ergebnisse. Die Testfälle sind als geplante Prüfungen gekennzeichnet.

Zehn Begriffe, zehn unterschiedliche Aufgaben

1. Owner: verantwortlich für Verwaltung und Betrieb

Der Owner hat weitreichende Kontrolle über den Flow: bearbeiten, Berechtigungen vergeben, Ausführungen überwachen und den Flow löschen. Bei einem solution-aware Cloud Flow können Owner, Co-Owner oder Administratoren den eingetragenen Owner ändern. Nach dem Wechsel haben der ursprüngliche und der neue Owner Co-Owner-Zugriff. Für geplante und automatisierte Flows wechselt außerdem die maßgebliche Owner-Lizenz; Microsoft nennt dafür eine mögliche Verzögerung von bis zu sieben Tagen. Speichern nach dem Wechsel kann die Umstellung sofort anstoßen.[1]

Wichtig: Der Owner des Flows ist nicht automatisch Eigentümer aller verwendeten Connections und nicht automatisch Business Owner des Prozesses.

2. Co-Owner: technische Vollmacht, kein Support-Leserecht

Ein Co-Owner darf die Run History sehen, Eigenschaften und Credentials verwalten, den Flow bearbeiten, weitere Owner hinzufügen oder entfernen und den Flow löschen.[2] Diese administrative Rolle gehört nur an Personen oder Gruppen, die den Flow tatsächlich entwickeln oder betreiben müssen.

Ein Co-Owner stabilisiert die Betreuung, ersetzt aber weder eine gültige Connection noch Credentials, Lizenz und Monitoring.

3. Run-only: ausführen, nicht umbauen

Run-only eignet sich für Nutzer, die einen Instant Flow auslösen sollen, ohne dessen Definition zu bearbeiten. Der Owner legt pro verwendeter Connection fest, ob die im Flow hinterlegte Connection oder eine vom ausführenden Nutzer bereitgestellte Connection verwendet wird.[3] Der Flow kann damit in einem zentralen technischen Kontext oder im Berechtigungskontext des Aufrufers arbeiten. Diese Entscheidung muss dokumentiert werden.

4. Connection: gespeicherte Authentifizierung zu einem Connector

Eine Connection ist die gespeicherte Authentifizierung für einen Connector, etwa OAuth-Anmeldedaten für SharePoint.[4] Sie ist ein laufzeitrelevantes Objekt im jeweiligen Environment. Entfernt man einen Owner, dessen Connection der Flow nutzt, können einzelne Aktionen ausfallen, obwohl der Flow selbst weiterhin einen aktiven Owner besitzt.[3]

5. Connection Reference: transportierbare Zuordnung, kein Geheimniscontainer

Eine Connection Reference ist eine Solution-Komponente, die für einen bestimmten Connector auf eine Connection verweist. Solution-aware Flows binden sich an diese Referenz statt direkt an die Connection.[4] Das macht die Zuordnung je Environment kontrollierbarer. Es überträgt aber keine nutzbaren Credentials in ein Zielsystem. Beim Import oder Deployment muss dort eine passende Connection bereitgestellt und der Connection Reference zugewiesen werden.

6. Credentials: das tatsächliche Anmeldegeheimnis

Credentials sind die Authentifizierungsdaten innerhalb der Connection. Ihr Lebenszyklus ist getrennt vom Flow zu steuern: verantwortliche Identität, Berechtigungsumfang, Ablauf oder Widerruf, Rotation und Notfallwechsel. Wer nur den Flow-Owner ändert, hat die Authentifizierung noch nicht migriert.

7. Lizenzierung und Request Limits: Laufzeitbedingung, kein Detail

Bei geplanten und automatisierten Flows kann die Lizenz des neuen Owners die Ausführung beeinflussen; manuelle Flows laufen laut Microsoft unter der Lizenz des ausführenden Nutzers.[1] Nutzt ein geplanter oder automatisierter Flow Premium-Features und der neue Owner besitzt keine passende Premium-Lizenz, beschreibt Microsoft eine 30-tägige Gnadenfrist; ohne Korrektur wird der Flow danach deaktiviert.[1] Ein Service Principal Application User ist nicht interaktiv, hat keine User-Lizenz und unterliegt Regeln für nicht lizenzierte Nutzer sowie besonderen Request-Limit- und Lizenzierungsimplikationen.[1] Deshalb gehört vor jedem Ownership-Wechsel eine aktuelle Prüfung des Flow-Typs, der verwendeten Features, der ausführenden Identität und der geltenden Microsoft-Lizenzbedingungen in das Change-Verfahren.

8. Solution: ALM-Container für versionierbare Komponenten

Solutions sind der Microsoft-Mechanismus für ALM in Power Apps und Power Automate. Microsoft empfiehlt unmanaged Solutions für die Entwicklung und managed Solutions für Umgebungen außerhalb der Entwicklung. Exportierte unmanaged Inhalte gehören in die Versionsverwaltung; das managed Paket ist das Build-Artefakt für Test, UAT und Produktion.[5]

9. Environment: technische und organisatorische Grenze

Ein Environment trennt Ressourcen, Rollen, Connections, Datenrichtlinien und Lebenszyklen. Für die Power-Platform-ALM-Funktionen müssen die beteiligten Environments eine Dataverse-Datenbank enthalten.[6] Dev, Test/UAT und Produktion sollten daher nicht nur unterschiedliche Namen sein, sondern klar definierte Verantwortlichkeiten, Zugriffspfade und Freigaberegeln besitzen.

10. Pipeline: kontrollierter Transport, nicht automatischer Betrieb

Power Platform Pipelines transportieren Solutions plus zielbezogene Konfiguration wie Connections, Connection References und Environment Variables. Dasselbe exportierte Artefakt durchläuft die Stages sequenziell; pro Deployment werden Solution-Artefakte im Pipeline-Host gespeichert.[7] Pipelines deployen nicht tenantübergreifend. Für diesen Fall verweist Microsoft auf Azure DevOps oder GitHub.[7]

Das ist ein belastbarer Release-Weg, aber kein Beweis für einen nach Import und Aktivierung funktionierenden Geschäftsprozess. Auch ein möglicher Redeploy einer früheren Solution-Version ersetzt keinen getesteten Recovery-Ablauf.[7]

Ownership wechseln: zwei unterschiedliche Wege

Für einen solution-aware Flow ist ein In-place-Wechsel möglich.[1] Danach sind mindestens drei Nacharbeiten nötig:

1. Lizenz- und Request-Limit-Auswirkung für die neue Owner-Identität prüfen.
2. Alle Connections und Connection References einschließlich Freigaben kontrollieren.
3. Flow speichern, aktivieren und mit fachlichen Testdaten ausführen.

Für einen nicht solution-aware Flow ist der Owner Teil der Flow-Identität; ein In-place-Wechsel ist nicht verfügbar. Gibt es Dataverse, empfiehlt Microsoft, den Flow zunächst einer Solution hinzuzufügen. Ohne Dataverse bleibt eine neue Flow-Instanz per Export/Import, Save as oder Send a copy.[1] Trigger, IDs, Aufrufer, Connections, Berechtigungen, Monitoring und abhängige Apps müssen danach erneut geprüft werden.

Für kritische oder langlebige Flows kann ein Service Principal Application User als Owner sinnvoll sein. Dafür muss ein Application User angelegt werden, die benötigten Connections müssen mit ihm geteilt werden, der Owner wird umgestellt und der Flow aktiviert. Ein Service Principal kann Flow-Owner, aber nicht Co-Owner sein.[1] Das entkoppelt Ownership von Beschäftigten, hebt aber keine Lizenz-, Request-Limit-, Connector- oder Berechtigungsanforderung auf.

Flow Operations & ALM Runbook

Das folgende Runbook kann pro produktivem Flow als Markdown-Seite, Listeneintrag oder kontrolliertes Betriebsdokument geführt werden.

A. Scope und Identität

• Tenant, Environment-ID und Environment-Typ
• Solution, Version, Publisher und Source-Control-Pfad
• Flow-Name, Flow-ID, Flow-Typ und Trigger
• solution-aware: ja/nein; Dataverse vorhanden: ja/nein
• Kritikalität, Datenklassifikation, Fachprozess und Betriebszeiten
• Business Owner mit fachlicher Abnahmeverantwortung
• Technical Owner für Wartung und Incident-Behandlung

B. Rollen- und Zugriffsregister

• eingetragener Flow-Owner und Identitätstyp: Nutzer, Servicekonto oder Application User
• Co-Owner mit Begründung und Review-Datum
• Run-only-Nutzer oder besser: Gruppen; je Connection „eingebettet“ oder „vom Aufrufer bereitgestellt“
• Environment Admins und relevante Dataverse-Sicherheitsrollen
• Trennung von Maker-, Betriebs-, Freigabe- und Endnutzerrechten
• Stellvertretung, Offboarding-Trigger und regelmäßige Rezertifizierung

Environment Admins und Nutzer mit umfassenden Rechten auf Workflow-Tabellen können Flows bearbeiten und Run History einsehen. Least Privilege muss daher auch Environment- und Dataverse-Rollen umfassen, nicht nur die Share-Funktion am Flow.[2]

C. Connection- und Credential-Register

Für jede Trigger- und Action-Verbindung:

• Connector und fachlicher Zweck
• Connection-ID und Environment
• Connection Owner beziehungsweise technische Identität
• Connection Reference: Name, logischer Name und zugeordnete Solution
• Authentifizierungsart; keine Secrets im Runbook speichern
• benötigte Zielsystemrechte und Freigaben
• Credential-Verantwortlicher, Rotationsverfahren und Ablaufwarnung
• DLP-Zuordnung, abhängige Systeme und Health-Check

Wer einen Flow aktiviert, muss alle Connections besitzen oder verwenden dürfen. Fehlt diese Berechtigung, kann ConnectionAuthorizationFailed auftreten.[4]

D. Lizenz- und Kapazitätsprüfung

• automatisiert, geplant, Instant oder anderer Flow-Typ
• lizenzrelevante Features und Connectoren
• maßgebliche ausführende beziehungsweise Owner-Identität
• Service-Principal-/Application-User-Nutzung
• Request-Limit-Annahmen und Monitoring-Schwellen
• Prüfdatum, Quelle und verantwortliche Person

Keine Lizenzentscheidung aus einem alten Runbook übernehmen. Produktbedingungen können sich ändern; die Prüfung erfolgt vor Go-live und bei Ownership-, Architektur- oder Connector-Wechsel.

E. Solution-, Environment- und Pipeline-Modell

• Dev: eigene unmanaged Solution mit festem Publisher; Änderungen in Source Control
• Test/UAT/Prod: managed Solution; keine ungeplanten unmanaged Anpassungen
• Solution-Version und Abhängigkeiten
• Environment Variables pro Stage, ohne Secrets im Quelltext
• Pipeline-Host, Source Environment, Target Environments und Stage-Reihenfolge
• Pipeline-Voraussetzung: Target Environments als Managed Environments führen und erforderliche Premium-Nutzungsrechte vor dem Pipeline-Design prüfen.[7]
• Deployment-Identität, Approval-Verantwortlicher und Separation of Duties
• Connection-Zuordnung je Ziel-Environment

F. Offboarding oder Owner-Wechsel

1. Change freigeben; Scope, Risiko und Rückweg dokumentieren.
2. Nachfolger oder Application User inklusive Rollen und Lizenzierung prüfen; bei Premium-Features den Lizenzstatus vor Ablauf der dokumentierten 30-Tage-Gnadenfrist bestätigen.[1]
3. solution-aware-Status feststellen; Transfer- oder Migrationsweg wählen.
4. Connections, Connection References und deren Freigaben inventarisieren.
5. Owner ändern oder kontrollierte neue Instanz erstellen.
6. Connections im Zielkontext zuordnen; Credentials rotieren, wenn die ausscheidende Identität beteiligt war.
7. Co-Owner und Run-only-Zugriffe nach Least Privilege bereinigen.
8. Flow speichern, aktivieren und die passenden TESTPLAN-Fälle ausführen.
9. Run History, Monitoring und abhängige Aufrufer kontrollieren.
10. Evidenz, fachliche Abnahme, Restabweichungen und nächsten Review-Termin erfassen.

G. Release und Recovery

1. Änderungen nur in Dev und in der unmanaged Solution vornehmen.
2. Version, Abhängigkeiten, Connection References und Environment Variables prüfen.
3. Managed Artefakt über dieselbe Pipeline nach Test/UAT und Produktion transportieren.
4. Approval und Deployment-Identität protokollieren.
5. Nach Deployment Connections zuordnen, Aktivierung prüfen und Smoke-Test ausführen.
6. Vorversion beziehungsweise Pipeline-Artefakt und zulässigen Redeploy-Weg dokumentieren.
7. Recovery in einer geeigneten Nicht-Produktivumgebung proben: Wiederherstellung, Connection-Zuordnung, Aktivierung, Smoke-Test.
8. Erst danach den Rückweg als betriebsfähig kennzeichnen.

Konkrete Testfälle

TESTPLAN – noch nicht ausgeführt. Ergebnisse dürfen erst nach einem protokollierten Lauf im benannten Tenant und Environment ergänzt werden.

TESTPLAN 1: Solution-aware Owner-Transfer

Setup: Automatisierter oder geplanter Solution Flow, User A als Owner, User B mit erforderlichen Rollen.
Schritte: Baseline-Lauf protokollieren; Owner A → B ändern; Flow speichern; Connection-Freigaben prüfen; Testereignis auslösen.
Erwartung: B ist neuer Owner; A und B besitzen anschließend Co-Owner-Zugriff; Flow wird aktiviert und der Lauf endet fachlich korrekt. Verwendete Lizenzzuordnung und Run History werden dokumentiert.[1]

TESTPLAN 2: Nicht solution-aware Flow

Setup: Kopie eines unkritischen Non-Solution-Flows.
Schritte: In-place-Transferoption prüfen; erwartetes Fehlen dokumentieren; mit Dataverse den Flow einer Solution hinzufügen und Connection References kontrollieren, andernfalls eine neue Instanz per freigegebenem Migrationsweg erstellen.
Erwartung: Kein In-place-Transfer am ursprünglichen Non-Solution-Flow; neue ID, Trigger, Connections und Aufrufer sind vollständig inventarisiert.[1]

TESTPLAN 3: Fehlende Connection-Freigabe

Setup: Solution Flow in Test; Ziel-Connection ist der aktivierenden Identität absichtlich nicht freigegeben.
Schritte: Import/Deployment und Aktivierung versuchen; Fehler und Correlation-Daten erfassen; Connection korrekt teilen beziehungsweise durch ihren Owner aktivieren lassen; erneut aktivieren und Testlauf starten.
Erwartung: Vor Freigabe schlägt die Aktivierung fehl; tatsächlichen Fehlercode und Correlation-ID protokollieren. ConnectionAuthorizationFailed ist ein möglicher Beobachtungshinweis, kein zugesichertes Ergebnis. Nach korrekter Zuordnung folgen erfolgreiche Aktivierung und fachlich korrekter Lauf.[4]

TESTPLAN 4: Service Principal als Owner

Setup: Application User, minimal erforderliche Rollen, unterstützte Connections, definierte Request-Limit- und Lizenzprüfung.
Schritte: Connections teilen; Owner auf Application User ändern; Flow aktivieren; Trigger auslösen; Monitoring prüfen; dokumentierten Rückwechsel auf menschlichen Owner in Test erproben.
Erwartung: Application User ist Owner, erscheint nicht als Co-Owner, kann freigegebene Connections nutzen; Lauf, Audit-Evidenz und Rückweg sind nachvollziehbar.[1]

TESTPLAN 5: Pipeline und Recovery

Setup: Versionierte unmanaged Solution in Dev, managed Zielartefakt, Pipeline Dev → Test/UAT → Prod, freigegebene Testdaten.
Schritte: dieselbe Version sequenziell deployen; Dependency-Prevalidation, Connection References, Environment Variables und Approval protokollieren; Smoke-Test je Stage; in Test eine frühere freigegebene Version über den vorgesehenen Weg redeployen; Connections neu validieren.
Erwartung: identisches Artefakt durchläuft die Stages; keine Stage wird übersprungen; Recovery endet erst nach erfolgreicher Aktivierung und Smoke-Test.[7]

Was wir sagen dürfen – und was nicht

Zulässige, belegbare Aussagen

• „Ein In-place-Ownership-Transfer setzt einen solution-aware Cloud Flow voraus.“[1]
• „Co-Owner können Flows ändern, Credentials verwalten und Flows löschen.“[2]
• „Run-only beschränkt Instant-Flow-Nutzer auf die Ausführung und erlaubt eine bewusste Wahl des Connection-Kontexts.“[3]
• „Connection References unterstützen den Transport der Zuordnung, enthalten aber nicht automatisch nutzbare Ziel-Credentials.“[4]
• „Ein Service Principal Application User kann Owner, aber nicht Co-Owner eines Flows sein.“[1]
• „Power Platform Pipelines sind nicht cross-tenant.“[7]

Nicht zulässige oder zu starke Aussagen

• „Ein Co-Owner oder Servicekonto verhindert Ausfälle.“ – Connections, Credentials, Rechte, Lizenzierung und Monitoring bleiben separate Abhängigkeiten.
• „Die Solution nimmt Secrets sicher mit.“ – Connection Reference und Connection/Credentials sind unterschiedliche Objekte.[4]
• „DLP löst Ownership und ALM.“ – DLP adressiert Datenrichtlinien, nicht Rollenübergabe, Authentifizierung oder Releases.
• „Die Pipeline garantiert ein funktionierendes Rollback.“ – Artefakte und Redeploy-Funktionen helfen, aber Recovery einschließlich Connections und Fachfunktion muss getestet werden.[7]
• „Der Flow läuft weiter, weil der frühere Owner noch Co-Owner ist.“ – Das ist ohne Laufzeit-, Connection-, Trigger- und Lizenzprüfung nicht belegt.
• „ALM macht den Prozess automatisch compliant.“ – ALM schafft kontrollierbare Abläufe; Compliance erfordert passende Anforderungen, Kontrollen und Nachweise.

Vom Flow zur betreibbaren Automatisierung

Power Automate ist oft das Bindeglied zwischen SharePoint, Fachanwendung und menschlicher Entscheidung. Wer die fachliche Basis noch strukturiert, findet im WITC-Beitrag SharePoint Online – Die Basis für modernes Dokumentenmanagement den passenden Einstieg. Für agentische Szenarien zeigt Power Automate + Copilot Studio: Wie mittelständische Unternehmen echte KI-Assistenten bauen, warum klare Prozesse und Datenzugriffe vor der Automatisierung geklärt werden müssen.

WITC kann bestehende Flows entlang des Runbooks inventarisieren und mit euch ein passendes Solution-, Environment- und Deployment-Modell erarbeiten. Der sinnvolle erste Schritt ist keine pauschale Migration, sondern eine belastbare Bestandsaufnahme: Welche Flows sind kritisch, welche Identitäten und Connections tragen sie, und welcher Recovery-Weg wurde tatsächlich getestet? Wenn ihr das strukturiert angehen wollt, nutzt den Kontakt zu Walther IT Consulting.

Weiterführende WITC-Artikel

• Power Automate + Copilot Studio: Wie mittelständische Unternehmen echte KI-Assistenten bauen
• SharePoint Online – Die Basis für modernes Dokumentenmanagement

Sources

[1] https://learn.microsoft.com/en-us/power-automate/change-cloud-flow-owner — Microsoft Learn: Change the owner of a cloud flow (abgerufen am 04.09.2026) [2] https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/understand-access-to-flows — Microsoft Learn: Understand flow ownership and access (abgerufen am 04.09.2026) [3] https://learn.microsoft.com/en-us/power-automate/create-team-flows — Microsoft Learn: Share a cloud flow (abgerufen am 04.09.2026) [4] https://learn.microsoft.com/en-us/power-apps/maker/data-platform/create-connection-reference — Microsoft Learn: Use a connection reference in a solution with Microsoft Dataverse (abgerufen am 04.09.2026) [5] https://learn.microsoft.com/en-us/power-platform/alm/solution-concepts-alm — Microsoft Learn: Solution concepts with Power Platform (abgerufen am 04.09.2026) [6] https://learn.microsoft.com/en-us/power-platform/alm/overview-alm — Microsoft Learn: Overview of ALM with Microsoft Power Platform (abgerufen am 04.09.2026) [7] https://learn.microsoft.com/en-us/power-platform/alm/pipelines — Microsoft Learn: Overview of pipelines in Power Platform (abgerufen am 04.09.2026)