Dataverse ist das am meisten unterschätzte Stück der Microsoft-Welt: keine sichtbare Oberfläche, kein „Wow" in der Demo — und trotzdem die Komponente, an der Power-Platform-Projekte am häufigsten scheitern oder gewinnen. Ist dein Datenmodell sauber, fühlt sich der Rest der Plattform leicht an. Steht es schief, kämpfst du jahrelang mit Workarounds, langsamen Views und Berechtigungen, die niemand mehr versteht.
Dieser Leitfaden ist die ehrliche Langfassung: was Dataverse wirklich ist, wann es passt (und wann nicht), wie du ein Datenmodell baust, das in fünf Jahren noch trägt, und wie das Security-Modell funktioniert, bevor es dich überrascht. Kein Marketing — sondern das, was wir aus echten Mittelstandsprojekten gelernt haben.
Dataverse ist die zentrale Datenplattform unter Power Platform und Dynamics 365. Technisch eine verwaltete, relationale Datenbank mit Logikschicht — aber das verfehlt den Punkt. Eine reine Datenbank bekommst du günstiger. Interessant macht Dataverse die Kombination aus drei Dingen, die sonst getrennt zu bauen wären:
Der Satz zum Merken: Dataverse ist datenzentrisch, nicht app-zentrisch. Du baust nicht eine App, die zufällig Daten speichert, sondern ein Datenmodell, um das herum mehrere Apps, Flows, Berichte und Integrationen entstehen. Wer diesen Perspektivwechsel nicht macht, baut Dataverse wie eine SharePoint-Liste — teurer, ohne den Mehrwert.
Das nächste Schaubild zeigt diese Schichtung. Lies es von unten nach oben: Daten zuerst, Apps zuletzt.
Ein häufiges Missverständnis: Dataverse sei „nur die Datenbank von Dynamics". Das war historisch der Ausgangspunkt (es hieß früher Common Data Service), heute ist es eine eigenständige Plattform. Du kannst Dataverse ohne ein einziges Dynamics-Modul betreiben — als Backend eigener Business-Apps, als Stammdaten-Drehscheibe oder als sicheren Datenlayer für Power-BI-Berichte.
Die ehrlichste Aussage zuerst: Dataverse ist nicht immer richtig. Es kostet Lizenzgeld pro Nutzer oder App, hat eine Lernkurve und ist für triviale Fälle überdimensioniert. Senior-Beratung heißt, das auszusprechen, bevor Budget verbrannt ist.
Dataverse passt gut, wenn:
Dataverse passt schlecht, wenn:
Die Detailabwägung gegen die beiden häufigsten Alternativen — Azure SQL und SharePoint Lists — haben wir mit Kosten, Limits und Migrationspfaden gegenübergestellt: Dataverse vs. SQL vs. SharePoint Lists. Wenn du vor genau dieser Entscheidung stehst, lies den Beitrag, bevor du weiterplanst.
Eine Einordnung, die in der Praxis hilft: Dataverse ist selten die billigste Option, aber häufig die mit den niedrigsten Folgekosten. Eine SharePoint-Liste ist heute günstig und in zwei Jahren ein Sanierungsfall, wenn das Team gewachsen ist. Rechne Total Cost of Ownership, nicht den Lizenzpreis isoliert.
Bevor wir über Best Practices reden, müssen die Bausteine sitzen. Wer hier unscharf ist, baut unscharfe Modelle:
Tabellen (Tables). Früher „Entity". Standardtabellen (Account, Contact, Activity …) erweiterst du, entkernst sie aber nicht; eigene Konzepte bekommen benutzerdefinierte Tabellen. Der Tabellentyp — Standard, Aktivität (Zeitbezogenes) oder Virtuell (externe Daten gespiegelt) — wird bei der Erstellung festgelegt; eine spätere Änderung ist faktisch eine Neumodellierung.
Spalten (Columns). Hier entscheidet sich Qualität im Detail. Wähle den engsten Datentyp: Auswahl ist Choice, kein Freitext; Betrag ist Currency mit Währung, kein Decimal; Ja/Nein ist Yes/No, kein String mit „ja"/„Ja "/„JA". Jede zu lasche Typwahl rächt sich bei Auswertung und Integration. Relevant auch: lokaler vs. globaler Choice — dazu Kapitel 5.
Beziehungen (Relationships). 1:N, N:1, N:N. Die wichtigste Designentscheidung ist das Beziehungsverhalten (Cascade Behavior): Was passiert mit Kind-Datensätzen, wenn der Eltern-Datensatz gelöscht, neu zugewiesen oder geteilt wird? Die Standardwerte sind selten die richtigen. Ein falsch konfiguriertes Cascade-Delete reißt beim Löschen eines Kunden hunderte verknüpfte Datensätze mit — einer der häufigsten Datenverluste in jungen Dataverse-Umgebungen.
Choices (Option Sets). Vordefinierte Werteliste. Klingt banal, entscheidet aber über Reporting: Ein Choice ist auswertbar und mehrsprachig, ein Freitextfeld mit denselben Werten nie.
Schlüssel (Alternate Keys). Oft übersehen: Mit einem Alternate Key identifizierst du einen Datensatz über ein fachliches Feld (Kundennummer, SKU) statt über die technische GUID. Für jede Integration, die Daten von außen einspielt, ist das fast immer Pflicht — sonst entstehen Dubletten.
Wie diese Bausteine zu einem tragfähigen Modell zusammenkommen, vertiefen wir hier: Datenmodellierung in Dataverse — Best Practices.
Ein Punkt, der in fast jedem ersten Dataverse-Projekt zu kurz kommt und sich bitter rächt: Application Lifecycle Management. Wer Tabellen direkt in Produktion anlegt und „später aufräumt", räumt nie auf.
Die Grundregeln, die wir durchsetzen:
Das nächste Schaubild zeigt den Solution-Fluss, wie wir ihn standardmäßig aufsetzen. Beachte die Richtung: Schema fließt nur in eine Richtung — von DEV nach PROD, nie zurück.
Dieses ALM-Fundament ist unsexy und kostet anfangs Disziplin. Aber es ist der Unterschied zwischen einer Plattform, die du in fünf Jahren noch ruhig erweiterst, und einer, die nach achtzehn Monaten niemand mehr anfasst. Das große Bild dazu: Power-Platform-Leitfaden für den Mittelstand.
Du kannst hundert kleine Entscheidungen falsch treffen, ohne dass es weh tut. Eine Handvoll prägt das ganze Projekt. Hier die, die am häufigsten den Unterschied gemacht haben.
Die Verlockung, alles in Account und Contact zu stopfen, ist groß. Faustregel: Ein eigenständiges fachliches Ding (Projekt, Asset, Vertrag) bekommt eine eigene Tabelle. Eine Eigenschaft eines bestehenden Dings (die Branche eines Kunden) wird eine Spalte an der Standardtabelle. Klingt offensichtlich, wird permanent verletzt — und jede Verletzung erschwert spätere Auswertung und Berechtigung.
Ein lokaler Choice lebt nur an einer Spalte, ein globaler ist projektweit wiederverwendbar. Regel: Wird ein Wertekatalog an mehr als einer Stelle gebraucht (Status, Priorität, Region), gehört er global — sonst pflegst du dieselbe Liste fünfmal und sie driften auseinander. Umgekehrt bleibt ein wirklich tabellenspezifischer Choice lokal, sonst vermüllt der globale Namensraum.
Soll „Abteilung" ein Choice oder eine eigene Tabelle mit Lookup sein? Faustregel: Ändern sich Werte selten und tragen keine eigenen Attribute (Priorität niedrig/mittel/hoch), ist ein Choice richtig. Tragen die Werte eigene Daten (Abteilung hat Kostenstelle, Leiter, Budget) oder werden von Fachanwendern gepflegt, ist es eine eigene Tabelle. Choices nachträglich in Tabellen umzubauen ist teuer.
Jedes „nehmen wir vorsichtshalber Text" ist eine Hypothek. Datum als Text zerstört jede Zeitauswertung, Betrag als Decimal verliert die Währung. In Sanierungsprojekten geht überraschend viel Zeit dafür drauf, zu lasche Typen zu reparieren — meist mit Datenmigration, weil Bestandswerte den engeren Typ nicht erfüllen.
Diese und weitere Regeln — Normalisierung versus Denormalisierung, Namenskonventionen, N
— behandeln wir mit Beispielen im Best-Practices-Beitrag zur Datenmodellierung.Wenn ein Dataverse-Projekt nach dem Go-Live in Aufruhr gerät, geht es meist um Berechtigungen. Entweder sieht jemand etwas, das er nicht sehen darf — oder, häufiger, jemand sieht etwas nicht, das er braucht, und niemand versteht warum.
Das Modell ist mächtig, hat aber eine steile Lernkurve, weil mehrere Konzepte ineinandergreifen:
Der entscheidende Modellwechsel: Berechtigungen sind additiv. Bei zwei Rollen gilt die jeweils großzügigere Einstellung — es gibt kein „Verbieten gewinnt". Wer das übersieht, baut Rollenchaos und wundert sich, warum eine vermeintlich restriktive Rolle nichts bewirkt, weil eine zweite Rolle still alles wieder aufmacht.
Das folgende Schaubild zeigt, wie eine Leseanfrage durch die Schichten läuft, bis feststeht, ob ein Datensatz sichtbar ist.
Unsere Empfehlung: Rollenzahl klein halten, nach Aufgaben statt Personen bauen, und jede Rolle mit einem echten Testnutzer in der Zielumgebung prüfen — nicht als Admin, der ohnehin alles sieht. Die häufigsten Fehler, inklusive Owner-versus-Team und Field-Level-Security, im Detail: Security Roles in Dataverse richtig aufsetzen. Wer Berechtigungen unterschätzt, zahlt nach dem Go-Live doppelt — im Vertrauen der Nutzer und im Sanierungsaufwand.
Dataverse entfaltet seinen Wert selten allein. Spätestens im zweiten Projektjahr soll es Daten mit dem ERP austauschen, Berichte in Power BI speisen oder ein Kundenportal versorgen. Drei Pfade, die in der Praxis tragen:
Ein wiederkehrender Architekturfehler: schwere Reporting-Abfragen direkt gegen die produktive Umgebung. Das verlangsamt die operativen Apps spürbar. Trenne operative und analytische Last früh — diese Entscheidung ist günstig auf dem Whiteboard und teuer in Produktion. Welcher App-Typ auf dieses Fundament passt, ordnen wir hier ein: Power Apps Canvas, Model-Driven und Power Pages im Vergleich.
Nach Häufigkeit:
Keiner dieser Fehler ist ein Plattformfehler. Es sind Modellierungs- und Disziplinfehler — am Anfang fast kostenlos vermeidbar, am Ende teuer. Das ist die Kernaussage dieses Leitfadens.
Dataverse belohnt Disziplin und bestraft Bequemlichkeit — beides mit Zinseszins. Die Plattform ist robust; was Projekte scheitern lässt, ist fast immer ein Datenmodell, das unter Zeitdruck zusammengeschoben und nie korrigiert wurde.
Drei Dinge zum Mitnehmen: Erstens, behandle Dataverse datenzentrisch — erst das Modell, dann die Apps. Zweitens, etabliere ALM mit getrennten Umgebungen und eigener Solution ab Tag eins, nicht „später". Drittens, nimm das Security-Modell ernst, bevor es dich nach dem Go-Live einholt.
Die teuerste Stunde im Dataverse-Projekt ist nicht die, in der du sauber modellierst — es ist die, in der du es zwei Jahre später noch einmal tust, mit Produktivdaten und unter Druck. Wer ehrlich plant, spart genau diese Stunde.
Ob Greenfield-Modellierung, Architektur-Review oder Sanierung eines gewachsenen Datenmodells — wir schauen ehrlich drauf und sagen dir, was trägt und was du dir sparen kannst. Kein Pitch, sondern eine fundierte Einschätzung.
