Dataflow und Dataverse: Welche Relationen klappen, welche nicht

Wer Daten mit einem Dataflow in Microsoft Dataverse schreibt, merkt schnell: einfache Felder und Standard-Lookups funktionieren problemlos. Aber sobald komplexere Beziehungen ins Spiel kommen, stösst der Dataflow an Grenzen. Das Problem liegt nicht beim Dataflow selbst, es liegt an der Architektur von Dataverse. Bestimmte Beziehungstypen und Systemfelder folgen internen Regeln, die ein Dataflow nicht kennt und nicht kennen kann. In diesem Post erklären wir, welche Relationen ein Dataflow schreiben kann, welche drei Typen systembedingt nicht funktionieren und wie du das architektonisch sauber löst.

Was ist ein Dataflow in Power Platform?

Ein Dataflow in Microsoft Power Platform ist ein cloud-basierter ETL-Prozess (Extract, Transform, Load), der Daten aus verschiedenen Quellen extrahiert, transformiert und strukturiert in Dataverse lädt. Er ist für deklaratives Schreiben von Datensätzen ausgelegt, nicht für die Ausführung von Prozesslogik.

Was ein Dataflow zuverlässig schreiben kann

Einfache Lookup-Relationen (N:1)

Klassische Lookup-Felder funktionieren einwandfrei. Ein Lookup-Feld bildet eine N:1-Beziehung ab: mehrere Datensätze verweisen auf einen Zieldatensatz. Der Dataflow befüllt das Lookup-Feld direkt.

Drei Voraussetzungen müssen erfüllt sein:

• Der Zieldatensatz existiert bereits in Dataverse.

• Ein eindeutiger Schlüssel ist vorhanden: GUID oder Alternate Key.

• Das Zielfeld ist ein klassisches Lookup-Feld, kein polymorphes Feld.

Sind diese Punkte gegeben, schreibt der Dataflow das Lookup zuverlässig.

Welche Relationen ein Dataflow nicht schreiben kann

Drei Beziehungstypen sind für Dataflows systembedingt gesperrt. Der Grund ist jeweils derselbe: Sie erfordern Logik, die ein Dataflow nicht ausführt.

1. Polymorphe Relationen (Multi-Table-Lookups)

Dataverse unterstützt Lookup-Felder, die auf mehrere Tabellen gleichzeitig verweisen können, sogenannte polymorphe Lookups. Das bekannteste Beispiel ist das Owner-Feld, das entweder auf einen Benutzer oder auf ein Team zeigen kann. Ein Dataflow-Mapping ist statisch: Es erwartet eine klar definierte Zielentität. Die dynamische Entscheidung («wenn Typ A dann Tabelle X, sonst Tabelle Y») ist keine Mapping-Funktion. Damit sind polymorphe Relationen für Dataflows nicht abbildbar.

2. Many-to-Many-Relationen (N:N)

N:N-Beziehungen werden in Dataverse nicht über ein Lookup-Feld, sondern über eine systemverwaltete Zwischentabelle (Intersect Table) realisiert. Dataverse erstellt und verwaltet diese Tabelle automatisch.

Ein Dataflow kann nicht in eine systemverwaltete Zwischentabelle schreiben. Das Setzen einer N:N-Beziehung erfordert eine separate API-Logik, die ausserhalb der Standard-Mapping-Funktionalität liegt.

3. Status und StatusCode (StateCode)

Statusfelder in Dataverse bestehen aus zwei verknüpften Attributen: StateCode (übergeordneter Zustand, z. B. Active / Inactive) und StatusCode (spezifischer Status innerhalb dieses Zustands). Die beiden Felder sind voneinander abhängig. Jeder StatusCode ist einem StateCode zugeordnet.

Zusätzlich können Status-Transition-Regeln definiert sein, die festlegen, welche Zustandswechsel erlaubt sind. Wegen dieser internen Abhängigkeiten können StateCode und StatusCode in Dataflows nicht direkt gemappt werden.

Relationstyp	Dataflow- tauglich?	Grund
N:1 Lookup (klassisch)	Ja	Direktes Mapping möglich
Polymorphe Lookups / Owner-Feld	Nein	Dataflow-Mapping ist statisch, kein dynamisches Ziel
N:N-Relationen	Nein	Systemverwaltete Intersect Table, kein Direktzugriff
StateCode / StatusCode	Nein	Abhängige Systemfelder mit Transition-Logik

Warum existieren diese Grenzen?

Dataflows sind für das deklarative Schreiben von Datensätzen gebaut. Sie führen keine Prozesslogik aus und berücksichtigen keine Metadaten-Abhängigkeiten.

Polymorphe Lookups, N:N-Beziehungen und Statusübergänge basieren aber genau darauf: sie brauchen Logik, Kontext und oft plattformseitige Validierung. Diese Limitation ist kein Bug, sie ist ein bewusstes Architekturmerkmal.

Die Grenze liegt nicht im Können des Dataflows, sondern in der Verantwortlichkeit: Daten laden ist seine Aufgabe. Prozesslogik ausführen nicht.

Die saubere Lösung: Staging + Automatisierung

Wer diese Relationen trotzdem setzen muss, braucht keine Workarounds, sondern eine zweistufige Architektur:

• Stufe 1: Dataflow schreibt strukturierte Daten in eine technische Staging-Tabelle in Dataverse.

• Stufe 2: Power Automate Cloud Flow liest die Staging-Tabelle, löst polymorphe Relationen auf, erstellt N:N-Verknüpfungen und setzt validierte Status-Transitions.

Diese Trennung von Struktur (Dataflow) und Logik (Automatisierung) entspricht den Architekturprinzipien innerhalb der Power Platform. Sie ist wartbar, erweiterbar und transparent.

Wir empfehlen dieses Muster generell immer dann, wenn Datenimport und Prozesslogik vermischt werden, nicht nur bei diesen drei Limitationen.

TL;DR

• Dataflows schreiben N:1-Lookups zuverlässig, wenn Zieldatensatz und Schlüssel vorhanden sind.

• Polymorphe Lookups, N:N-Relationen und StateCode/StatusCode sind systembedingt nicht über Dataflows setzbar.

• Die Ursache liegt in der Dataverse-Architektur, nicht in einem Fehler des Dataflows.

• Lösung: Dataflow für die Datenlast, Power Automate für die Beziehungs- und Prozesslogik.

• Stehst du vor einer ähnlichen Architekturentscheidung? Wir schauen's uns gerne gemeinsam an.

FAQ

Kann ein Dataflow N:N-Relationen in Dataverse schreiben?

Nein. N:N-Beziehungen werden in Dataverse über eine systemverwaltete Zwischentabelle (Intersect Table) abgebildet, auf die Dataflows keinen Schreibzugriff haben. Der empfohlene Weg führt über Power Automate oder serverseitige Plugins.

Warum kann ich das Owner-Feld nicht per Dataflow setzen?

Das Owner-Feld ist ein polymorphes Lookup. Es kann entweder auf einen Benutzer oder auf ein Team zeigen. Ein Dataflow-Mapping ist statisch und kann diese dynamische Entscheidung nicht ausführen. Setze das Owner-Feld in einem nachgelagerten Cloud Flow.

Was ist der einfachste Weg, StateCode per Dataflow zu setzen?

Gar nicht. Das ist nicht möglich. StateCode und StatusCode sind voneinander abhängige Systemfelder mit Transition-Logik. Importiere die Basisdaten per Dataflow in eine Staging-Tabelle, dann setze den Status in einem separaten Power-Automate-Flow mit dem korrekten API-Aufruf (SetStateDynamicsEntityRequest oder HTTP-Aktion gegen die Dataverse API).

Gilt das nur für Dataflows oder auch für andere Importmethoden?

Die Einschränkungen betreffen spezifisch Power Platform Dataflows. Bei direkten API-Aufrufen (z. B. über Power Automate oder das SDK) können N:N-Relationen und StatusCode gesetzt werden. Dort übernimmst du aber selbst die Prozesslogik, die der Dataflow nicht mitbringt.