Wolkenkunde
← Blog
Platform Engineering·16. Juli 2026·11 min Lesezeit

Der Flow ist deployt – und trotzdem aus. Connection References von Dev bis Prod

Warum eine Solution sauber importiert und der Flow trotzdem nicht läuft. Was Connections und Connection References technisch wirklich sind, wie sie beim Weg von Dev über UAT nach Prod gebunden werden, welche Namenskonvention trägt – und warum du sie im Team niemals an deinem persönlichen Account aufhängst.

Die Solution ist grün durchgelaufen. Import erfolgreich, keine Fehler. Und in Produktion steht der Flow trotzdem still, mit einem Banner, das jeder kennt, der einmal von Dev nach Prod deployt hat:

This flow is turned off because a connection reference used in it is not configured.

Nichts ist kaputt. Der Import war korrekt. Und genau das ist der Punkt, an dem die meisten das Falsche tun: Sie öffnen den Flow in Prod, klicken schnell eine eigene Verbindung hinein, schalten ihn wieder ein – und haben sich damit das nächste Deployment-Problem gebaut. Dieser Artikel erklärt, was zwischen Connection und Connection Reference technisch passiert, wie das Binding über Dev → UAT → Prod funktioniert, wie du benennst, und mit welchem Konto du im Team arbeitest.

Was man zuerst sieht

Der sichtbare Befund ist immer derselbe:

  • In Dev läuft der Flow einwandfrei – dort hast du die Verbindung selbst angelegt, sie ist gebunden, alles gut.
  • Nach dem Import in UAT oder Prod ist der Flow ausgeschaltet oder wirft beim ersten Trigger einen Fehler.
  • Öffnest du ihn, zeigt die Connection Reference kein Ziel – das Dropdown „Connection” ist leer.

Der importierte Flow ist ausgeschaltet: die Connection Reference (Microsoft Dataverse) ist rot als „nicht konfiguriert“ markiert, Status „Off“. Genau das passiert, wenn nach dem Import kein Binding gesetzt ist.

Der reflexhafte Schluss lautet: „Der Import hat die Verbindung vergessen.” Hat er nicht. Er hat sie bewusst nicht mitgenommen. Um zu verstehen, warum das richtig ist, muss man die beiden Dinge sauber trennen, die im Alltag ständig in einen Topf geworfen werden.

Was technisch wirklich passiert

Die konkreten Verbindungen der Umgebung (mit Credentials). Auf genau eine davon zeigt die Connection Reference pro Umgebung.

Es gibt zwei Objekte, und sie leben in zwei völlig verschiedenen Welten.

Die Connection ist die konkrete, authentifizierte Verbindung zu einem Dienst – dein Office-365-Outlook-Zugang, eine bestimmte SQL-Verbindung, ein Dataverse-Zugang. Sie enthält die eigentlichen Credentials bzw. OAuth-Tokens, sie gehört einem Benutzer (oder einem Service Principal), und sie ist an genau eine Umgebung gebunden. Eine Connection ist kein Solution-Bestandteil. Sie wird niemals mit exportiert und niemals zwischen Umgebungen transportiert – aus gutem Grund: Zugangsdaten haben in einem Solution-Artefakt nichts verloren.

Die Connection Reference ist eine dünne Zwischenschicht: eine Solution-Komponente, die als Zeiger dient. Der Flow bindet nicht mehr direkt an eine Connection, sondern an die Connection Reference – und die Connection Reference zeigt pro Umgebung auf die dort vorhandene Connection. Die Reference reist mit der Solution mit; die Connection, auf die sie zeigt, wird in jeder Umgebung neu zugewiesen (gebunden).

Flow ──bindet an──▶ Connection Reference ──zeigt (pro Umgebung) auf──▶ Connection (Credentials)
        (reist in der Solution mit)        (Binding je Umgebung)        (bleibt in der Umgebung)

Vor Connection References (bis ~2020) hing der Flow direkt an einer Connection. Der Export schrieb dann die Verbindung des Dev-Makers in die Solution – und in Prod lief der Geschäftsprozess plötzlich unter dem persönlichen Account eines Entwicklers. Genau diese Kopplung lösen Connection References auf: Flow-Logik (transportabel) wird von Identität und Credentials (umgebungslokal) getrennt.

Daraus folgt direkt das Bild aus Prod: Der Import hat die Connection Reference korrekt mitgebracht. Nur das Binding an eine konkrete Prod-Connection fehlt noch. Ein leeres Binding = Flow aus. Das ist kein Bug, das ist der Vertrag.

Die naheliegende, aber falsche Lösung

Zwei Reflexe – beide verständlich, beide bauen technische Schulden.

Reflex 1: In Prod schnell selbst verdrahten. Man öffnet den Flow in Produktion, legt mit dem eigenen Konto eine Verbindung an, bindet sie ein, schaltet ein. Funktioniert – bis:

  • dein Account ein Passwort ändert, MFA neu greift oder du das Unternehmen verlässt → der Prod-Prozess stirbt still,
  • der nächste Solution-Import die manuelle Nacharbeit wieder in Frage stellt,
  • niemand mehr weiß, unter welcher Identität der Geschäftsprozess eigentlich läuft.

Produktion an einem persönlichen Postfach ist keine Lösung, sondern eine Zeitbombe mit Personalabhängigkeit.

Reflex 2: Connection References pro Umgebung benennen – CRM_Dataverse_Dev, CRM_Dataverse_Prod. Klingt sauber, ist aber ein Denkfehler: Die Connection Reference ist eine Solution-Komponente mit festem Schema-Namen, der mit der Solution wandert. In allen Umgebungen ist es dieselbe Komponente mit demselben logischen Namen – nur das Binding unterscheidet sich. Ein _Prod-Suffix im Schema-Namen erzeugt keine umgebungsspezifische Referenz, sondern höchstens Verwirrung (oder, wenn man es „richtig” falsch macht, zwei getrennte Komponenten und doppelte Pflege). Die Umgebung steckt im Binding, nicht im Namen.

Die belastbare Lösung dreht beide Reflexe um: Identität raus aus der Person, Umgebung raus aus dem Namen.

Die belastbare Lösung

Vier Prinzipien, die zusammen den Unterschied machen:

  1. Connection References explizit und früh anlegen. Baust du einen Flow in einer Solution, ohne vorher eine Connection Reference zu setzen, erzeugt die Plattform automatisch eine – mit einem kryptischen, GUID-behafteten Namen wie new_sharedoffice365_a1b2c3. Das funktioniert, ist aber in den Deployment Settings später kaum lesbar. Lege die Reference bewusst zuerst an, gib ihr einen sprechenden Namen, und binde den Flow daran.
  2. Nicht an Personen hängen – Service-Account oder Service Principal. Die Connection, auf die in Prod gebunden wird, gehört einem dedizierten Dienstkonto, nicht dir. Wo der Connector es unterstützt (z. B. Dataverse, viele Azure-Connectors), nimm einen Service Principal (Application User) mit Client-ID/Secret oder Federated Credential – keine Credentials, die ablaufen, keine Person, die kündigt. Wo der Connector nur Benutzerauth kann (SharePoint, Office 365 Outlook), nimm ein lizenziertes Service-Konto wie svc-powerplatform@deinedomain – geteilt im Team, im Passwort-Tresor, mit dokumentiertem Owner.
  3. Schema-Name über alle Umgebungen identisch halten. Dev, UAT und Prod tragen dieselbe Connection Reference mit demselben logischen Namen. Nur so mappt eine Deployment-Settings-Datei deterministisch, und nur so ist ein automatisierter Deploy reproduzierbar.
  4. Binding automatisieren, nicht in Prod klicken. Das Zuordnen „welche Reference → welche Connection” gehört in eine Deployment-Settings-Datei bzw. in die Pipeline, nicht in die manuelle Nacharbeit. Einmal pro Umgebung gepflegt, danach bei jedem Release automatisch.

Und die Frage aus dem Team-Alltag – „soll ich das mit speziellen Usern einrichten, wenn ich im Team arbeite?” – hat damit eine klare Antwort: Ja. Nicht als Kür, sondern als Grundlage. Dev-Connections dürfen an deinem Account hängen; jede Connection ab UAT gehört einem Dienstkonto, das nicht an einer einzelnen Person klebt.

Hands-on: Von Dev nach Prod mit pac CLI

Ein echter Lauf: CLI installieren, an der Umgebung anmelden, die Solution managed exportieren.

Jetzt praktisch. Ziel: eine Solution exportieren, eine Deployment-Settings-Datei erzeugen, die Connection-Bindings für die Ziel-Umgebung eintragen und managed importieren. Alles mit der Power Platform CLI (pac).

1. Anmelden und Solution exportieren

# CLI installieren (einmalig), falls noch nicht vorhanden
dotnet tool install --global Microsoft.PowerApps.CLI.Tool

# An der Dev-Umgebung anmelden
pac auth create --name dev --environment https://deinorg-dev.crm4.dynamics.com

# Managed exportieren (Prod-Import ist immer managed)
pac solution export --name KundenService --managed true --path ./KundenService_managed.zip

2. Deployment-Settings-Datei erzeugen

pac liest die Solution und schreibt ein Template mit allen Connection References und Environment Variables:

pac solution create-settings \
  --solution-zip ./KundenService_managed.zip \
  --settings-file ./deploymentSettings.prod.json

Heraus kommt ein Gerüst mit leeren Connection-IDs – das ist der Teil, den du pro Umgebung füllst:

{
  "EnvironmentVariables": [
    { "SchemaName": "wk_ServiceBaseUrl", "Value": "" }
  ],
  "ConnectionReferences": [
    {
      "LogicalName": "wk_dataverse_serviceprincipal",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
    },
    {
      "LogicalName": "wk_office365_servicemailbox",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365"
    }
  ]
}

3. Connection-IDs der Ziel-Umgebung besorgen

create-settings erzeugt die Datei; pac connection list liefert die Connection-IDs, die du bei ConnectionId einträgst.

Die ConnectionId ist eine umgebungsspezifische GUID – die Prod-Connection, die einem Dienstkonto/Service Principal gehört. Zwei Wege, sie zu finden:

# An Prod anmelden und die dort vorhandenen Verbindungen auflisten
pac auth create --name prod --environment https://deinorg-prod.crm4.dynamics.com
pac connection list
Connection Id                         Name                              Connector
------------------------------------  --------------------------------  -----------------------------
7b2f1e94-5c3a-4d21-9f0e-1a2b3c4d5e6f  SVC Dataverse (Service Principal) shared_commondataserviceforapps
c9d8e7f6-4b3a-2c1d-0e9f-8a7b6c5d4e3f  SVC Sammelpostfach (Outlook)      shared_office365

Alternativ steht die GUID in der URL, wenn du die Verbindung unter make.powerapps.com → Verbindungen öffnest. Trage sie ein:

"ConnectionReferences": [
  {
    "LogicalName": "wk_dataverse_serviceprincipal",
    "ConnectionId": "7b2f1e94-5c3a-4d21-9f0e-1a2b3c4d5e6f",
    "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
  },
  {
    "LogicalName": "wk_office365_servicemailbox",
    "ConnectionId": "c9d8e7f6-4b3a-2c1d-0e9f-8a7b6c5d4e3f",
    "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365"
  }
]

4. Managed importieren – mit Bindings

Der echte Import: ohne Settings wird der Flow deaktiviert („deactivated and replaced"); mit --settings-file bindet er und meldet „imported successfully". pac schreibt keine wörtliche „N bound"-Zeile.

pac solution import \
  --path ./KundenService_managed.zip \
  --settings-file ./deploymentSettings.prod.json \
  --activate-plugins true \
  --publish-changes true

Erfolgs-Ausgabe (gekürzt):

Connected to... prod
Solution Importing...
Solution 'KundenService' imported successfully.

Die Connection References sind jetzt gebunden, der Flow startet ohne manuelles Nachklicken. Genau dieselbe Settings-Datei – nur mit anderen GUIDs – nimmst du für UAT (deploymentSettings.uat.json). Der Rest ist per Environment identisch.

Die von pac solution create-settings erzeugte Datei: der LogicalName der Connection Reference steht fest, die ConnectionId füllst du pro Zielumgebung.

5. Service-Principal-Connection für Dataverse (der robuste Fall)

Damit Punkt 2 von oben real wird, hier der Dataverse-Fall mit Service Principal statt Benutzer:

# 1) Application User in der Ziel-Umgebung anlegen (App-Registrierung/Client-ID vorausgesetzt)
pac admin application-list                     # verfügbare App-Registrierungen prüfen
pac admin application register --application-id <app-client-id>

# 2) In make.powerapps.com eine Dataverse-Verbindung "Mit Service Principal verbinden"
#    anlegen: Client-ID, Tenant-ID, Client-Secret. Diese Connection-GUID kommt in
#    deploymentSettings.prod.json unter wk_dataverse_serviceprincipal.

Der Flow läuft in Prod damit unter der App-Identität – kein Passwortablauf, keine Personenbindung, höhere API-Limits als bei Benutzerkonten. Für Connectors ohne SPN-Unterstützung (SharePoint, Outlook) bleibt es beim dedizierten Service-Konto mit Lizenz; das Prinzip „nicht die eigene Person” gilt trotzdem.

Der Dataverse-Verbindungsdialog mit Authentifizierungstyp „Dienstprinzipal“ – Client-ID, geheimer Clientschlüssel und Mandant der Entra-Anwendung.

Namenskonvention, die trägt

Ein Muster, das in Deployment-Settings lesbar bleibt und Wiederverwendung fördert:

<Präfix>_<Connector>_<Zweck/Identität>
BeispielBedeutung
wk_dataverse_serviceprincipalDataverse, per Service Principal (der Standard für ALM)
wk_office365_servicemailboxOutlook über das geteilte Service-Postfach
wk_sql_salesdbSQL-Verbindung zur Sales-Datenbank
wk_sharepoint_projektsiteSharePoint auf die Projekt-Site

Regeln dahinter:

  • Publisher-Präfix statt new_ – setzt euren Solution-Publisher, dann ist die Herkunft sofort klar.
  • Connector + Zweck, nicht der Flow-Name: Eine Connection Reference wird von mehreren Flows geteilt, die dieselbe Identität nutzen. Nicht „eine pro Flow”, sondern „eine pro Connector-plus-Identität”.
  • Keine Umgebung im Namen – kein _Dev/_Prod. Die Umgebung steckt im Binding (Schritt 3), nicht im Schema-Namen.
  • Sprechend genug fürs Settings-JSON: Wer die Datei sechs Monate später öffnet, muss ohne Nachschlagen wissen, welche Verbindung gemeint ist.

Diagnose- und Entscheidungscheckliste

Wenn ein Flow nach dem Deploy nicht läuft:

  • Banner lesen – „connection reference … not configured” heißt: Binding fehlt, nicht Import fehlgeschlagen.
  • Gibt es in der Ziel-Umgebung überhaupt eine passende Connection? Ohne Connection kein Binding. Erst Connection (Dienstkonto/SPN) anlegen, dann binden.
  • Stimmt der LogicalName in der Settings-Datei mit der Reference in der Solution überein? Tippfehler = stilles Nicht-Binden.
  • Zeigt die Connection Reference auf eine Connection eines Dienstkontos – oder versehentlich auf deinen persönlichen Account?
  • Neuer Flow hinzugekommen? Dann gibt es eine neue Connection Reference → Deployment-Settings-Datei vor dem nächsten Release ergänzen, sonst kippt der Import genau diesen einen Flow.

Beim Aufsetzen im Team:

  • Dev-Connections dürfen persönlich sein; ab UAT nur Dienstkonten/SPN.
  • Service Principal, wo der Connector es kann; sonst lizenziertes Service-Postfach.
  • Eine Deployment-Settings-Datei pro Umgebung, versioniert im Repo (ohne Secrets!).

Grenzen und die unbequemen Teile

  • Nicht jeder Connector kann Service Principal. Dataverse und die meisten Azure-Connectors ja; SharePoint, Outlook, viele SaaS-Connectors nein. Dort brauchst du ein echtes, lizenziertes Service-Konto – inklusive Kosten und Passwort-/MFA-Verwaltung.
  • Connection References gibt es nur innerhalb einer Solution. Ein Flow außerhalb jeder Solution kann keine nutzen – ein weiterer Grund, konsequent solution-basiert zu arbeiten.
  • Leere Bindings lassen sich nicht „nachschieben”, wenn nie eines gesetzt war. Eine Connection Reference, die im Ziel noch nie einen Wert hatte, wird per Deployment Settings gesetzt; ändern lässt sich später problemlos, aber der erste Wert muss existieren.
  • Delegated Deployment (Pipelines, seit 2024/2025) verschiebt die Identität des Deployments selbst auf einen Service Principal – das ist die konsequente Fortsetzung dieses Musters, aber ein eigenes Thema: Der S2S-User braucht die Rolle Deployment Pipeline Administrator im Host und Systemadministrator im Ziel.
  • Environment Variables sind das Geschwister-Konzept. Was Connection References für Identitäten leisten, leisten Environment Variables für Konfigurationswerte (URLs, IDs). Beide stehen in derselben Deployment-Settings-Datei – wer das eine sauber macht, macht meist auch das andere.

Kurz: Der leere Flow in Prod ist kein Defekt, sondern die Stelle, an der sich zeigt, ob deine Identitäten sauber getrennt sind. Trenne Logik von Credentials, häng Prod an ein Dienstkonto statt an dich, halt die Namen stabil und das Binding automatisiert – dann ist „This flow is turned off” das letzte Mal ein Rätsel und ab dann nur noch eine Checkliste.

Stand der Programme, Rollen und CLI-Befehle: Juli 2026. Microsoft ändert Connector-Fähigkeiten und Pipeline-Features regelmäßig – im Zweifel die jeweilige Learn-Seite gegenprüfen.

Siehe auch