MDM Lite 1.3 – Release Notes

Release: 1.3.0 (6. Oktober 2026)

Mit Version 1.3 arbeiten Sie mit mehreren Umgebungen auch auf der Datenplattform und im Datenkatalog. Jede Umgebung, zum Beispiel Entwicklung, Test und Produktion, liefert in ihr eigenes Ziel in Microsoft Fabric und registriert ihre Datasets in ihrer eigenen Microsoft-Purview-Konfiguration. KI-Zugriff und Notebooks lassen sich ebenfalls je Umgebung steuern. Dazu kommen die Pflegeart und eine verantwortliche Person je Dataset, berechnete Spalten, gesammeltes Bearbeiten von Spalten, das Zurücksetzen des Spaltenstands und das Kopieren in eine andere Umgebung samt Beziehungen.

Wichtig für Administratoren

Vor dem Deploy prüfen: API-Importe und die neue Pflegeart. Jedes Dataset hat mit 1.3 eine Pflegeart. Alle bestehenden Datasets sind danach „Manuell gepflegt". Ab dem Deploy weist MDM Lite jeden schreibenden Zugriff auf Zeilen über einen API-Key in ein solches Dataset mit 409 und dem Code MAINTENANCE_TYPE_MISMATCH ab, nicht nur Importe. Das betrifft den Import, Massenänderungen von Zeilen, das Übernehmen von Änderungen (Commit), das Wiederherstellen einer Version und das Ändern von Baum-Knoten. Die Abweisung erfolgt, bevor MDM Lite etwas liest oder schreibt: Es entstehen weder Daten noch eine Version noch ein Eintrag im Änderungsprotokoll. Prüfen Sie deshalb vor dem Deploy, ob es in den letzten Wochen API-Importe gab (Aktion import_api im Änderungsprotokoll):
```
SELECT e."TenantId", e."DatasetId", d."Name" AS dataset,
       COUNT(*) AS api_imports, MAX(e."OccurredAt") AS last_api_import
FROM "AuditEvents" e
LEFT JOIN "Datasets" d ON d."Id" = e."DatasetId"
WHERE e."Action" = 'import_api'
  AND e."OccurredAt" >= now() - interval '8 weeks'
GROUP BY e."TenantId", e."DatasetId", d."Name"
ORDER BY last_api_import DESC;
```
Jedes Dataset in diesem Ergebnis lassen Sie direkt nach dem Deploy vom Mandanten-Admin auf „Automatisch geliefert" umstellen (Dataset → Verwaltung → Pflegeart), sonst laufen die automatischen Lieferungen ins Leere. Die Abfrage erfasst nur Importe. Schreiben Ihre Quellsysteme Zeilen auf einem anderen Weg per API-Key (Massenänderung, Commit, Wiederherstellen, Baum-Knoten), stellen Sie auch diese Datasets um. Abgewiesene Importe erscheinen in der Import-Historie des Datasets (Status Rejected, Kanal api); die übrigen Abweisungen hinterlassen keinen Eintrag, das Quellsystem erhält nur die Antwort 409. Der Datei-Upload und das Bearbeiten in der Weboberfläche sind von der Regel nicht betroffen. Ebenfalls nicht betroffen sind das Kopieren in eine andere Umgebung und das Neuberechnen berechneter Spalten.
Rollback-Grenze. Nach dem Deploy von 1.3 ist ein Rückbau auf einen Stand vor 1.3 nur sicher, solange keine Nicht-Live-Konfiguration für Microsoft Fabric existiert. Ein älterer Stand kennt Umgebungen bei Integrationen nicht und könnte eine solche Konfiguration für Live nutzen und Daten einer Test-Umgebung in das falsche Ziel schreiben. Sobald jemand eine Umgebung außer Live eingerichtet hat, ist ein Rückbau nur noch nach Entfernen dieser Konfigurationen zulässig. Klären Sie das mit dem Betrieb, bevor Sie 1.3 für Ihre Anwender freigeben.
Rollback-Grenze für Microsoft Purview. Dasselbe gilt für Purview: Ein Rückbau auf einen Stand vor 1.3 ist nur zulässig, solange keine Purview-Konfiguration für eine Umgebung außer Live existiert. Entfernen Sie solche Konfigurationen vor einem Rückbau. Assets, die MDM Lite bis dahin aus Nicht-Live-Umgebungen in Purview registriert hat, bleiben in Purview stehen, ebenso ihre Lineage. Sie erkennen sie am Umgebungsteil im Schlüssel (rdm://{Mandant}/{Umgebungs-Slug}/{Dataset-ID}, Lineage-Tabellen dwh://{Mandant}/environments/{Umgebungs-Slug}/…). Bereinigen Sie sie nach dem Runbook zur Bereinigung von Altartefakten (Betriebs-Runbook, erhältlich über den Support).
Purview je Umgebung. Jedes Dataset geht nur an die Purview-Konfiguration seiner eigenen Umgebung. Hat eine Umgebung keine eigene, aktivierte Konfiguration, registriert MDM Lite dort nichts, und die Live-Konfiguration springt nie ein. Ihre bestehende Konfiguration gehört Live und arbeitet unverändert weiter; bestehende Assets behalten ihren Schlüssel. Optional legen Sie je Umgebung eine Ziel-Collection fest (Referenzname der Collection in Purview); ohne Angabe landen neue Assets wie bisher in der Standard-Collection. Das Webhook-Secret gilt je Umgebung: Richten Sie für jede Umgebung ein eigenes Event-Grid-Abonnement mit deren Secret ein.
Bereitstellung je Umgebung. Jede Umgebung liefert ausschließlich in ihr eigenes Ziel. Hat eine Umgebung kein Ziel, überträgt MDM Lite nichts, und es greift nie das Ziel von Live ein. Ihre bestehende Konfiguration bleibt Live zugeordnet und liefert unverändert weiter. Konfigurationen aus der Zeit vor den Umgebungen, die noch keiner Umgebung gehören, erscheinen in Live und werden mit Speichern Live zugeordnet. Siehe Bereitstellung je Umgebung einrichten und Pro Umgebung einrichten.
Geänderte Antworten für Aufrufer mit einer Umgebung außer Live. Exportaufrufe mit dem Header X-Environment einer Nicht-Live-Umgebung antworteten bisher mit 409 (live_environment_required). Jetzt gilt:
- Hat die Umgebung ein eigenes Ziel, ist der Aufruf erfolgreich und schreibt in dieses Ziel.
- Hat sie keines, antwortet MDM Lite mit 503 und fabric_target_not_configured.
- „Jetzt synchronisieren" (export-all) betrifft die Umgebung des Aufrufs und nicht mehr immer Live.
- Der manuelle Purview-Sync (POST /api/datasets/{id}/purview-sync) für ein Dataset einer Umgebung außer Live antwortete bisher ebenfalls mit 409 (live_environment_required). Jetzt ist er erfolgreich, wenn die Umgebung eine eigene Purview-Konfiguration hat, sonst antwortet MDM Lite mit 400 und "status": "skipped". Prüfen Sie Automatisierungen, die auf das frühere 409 reagiert haben.
KI-Zugriff (MCP) in Nicht-Live-Umgebungen ist standardmäßig aus. Wer /mcp mit dem Header X-Environment oder /mcp/{Umgebungs-Slug} für eine Umgebung außer Live nutzt, bekommt ohne Freigabe 404. Ein Mandanten-Admin schaltet den Zugriff je Umgebung unter Einstellungen → Integrationen → MCP-Server (KI-Zugriff) mit „KI-Zugriff (MCP) für diese Umgebung erlauben" ein. Für Live ändert sich nichts. Siehe MCP-Onboarding.
Notebook-Erzeugung in Nicht-Live-Umgebungen ist standardmäßig aus. Wer bisher Notebooks in einer Umgebung außer Live erzeugt hat, schaltet die Erzeugung dort einmalig unter Einstellungen → Integrationen → Notebooks ein. Bereits erzeugte Notebooks laufen weiter. Siehe Schnellstart.
Bestehende Aufräumlisten prüfen. Exporte und Purview-Registrierungen von Datasets außerhalb von Live sind mit 1.3 legitim. Das Runbook zur Bereinigung von Altartefakten (Betriebs-Runbook, erhältlich über den Support) bezieht sich nur noch auf Artefakte vor dem Deploy von 1.3, die nicht im heutigen Ziel der Umgebung liegen.
Kunden-IT: Berechtigen Sie den Service Principal je Ziel-Workspace. Wir empfehlen einen eigenen Service Principal je Umgebung. Siehe Leitfaden für die Kunden-IT.
Einmalige Neuprüfung nach dem Deploy (Berechnete Spalten). Mit 1.3 gilt eine neue Prüfregel für die Auslieferung (COMPUTED_VALUE_MISMATCH, Regelstand 3). Deshalb validiert MDM Lite jedes Dataset beim nächsten Schreibzugriff einmal vollständig. Bei großen Datasets kann dieser erste Schreibzugriff nach dem Deploy spürbar länger dauern; danach prüft MDM Lite wieder nur die geänderten Zeilen. Es ist keine Aktion nötig. Stimmt der gespeicherte Wert einer berechneten Spalte nicht mit der Berechnung überein, stellt MDM Lite diese Version nicht bereit. Der Dataset-Admin gleicht die Werte dann mit dem Neuberechnen-Endpunkt ab, siehe Werte weichen von der Berechnung ab. Das gilt auch nach einem Rückbau auf einen Stand vor 1.3, wenn dazwischen Datasets mit berechneten Spalten geändert wurden.

Neu

Pflegeart je Dataset. Mandanten-Admins legen unter Verwaltung fest, ob ein Dataset „Manuell gepflegt" oder „Automatisch geliefert" ist, bei Bedarf mit einem erwarteten Lieferrhythmus. Der Hinweis „Veraltet" in der Übersicht entfällt. Stattdessen erscheint „Lieferung überfällig" nur bei automatisch gelieferten Datasets mit gesetztem Rhythmus. Wer ein automatisch gefülltes Dataset von Hand bearbeitet, sieht einen Hinweis, dass die nächste Lieferung die Änderung überschreiben kann. Die Regel gilt für alle schreibenden Zeilenzugriffe per API-Key, siehe Pflegeart eines Datasets.
Verantwortliche Person je Dataset. Jedes Dataset hat genau eine verantwortliche Person (Owner), unabhängig vom Ersteller. Neue Datasets bekommen die anlegende Person, bestehende Datasets die Person, die sie angelegt hat. Dataset-Admins und Mandanten-Admins ändern sie unter Verwaltung → Verantwortlich. Zur Auswahl stehen aktive Mitglieder mit mindestens Editor-Recht auf dem Dataset, die Zuweisung vergibt keine Rechte. Die Kopfzeile und die Übersicht zeigen die verantwortliche Person (bisher stand dort die Person der letzten Änderung), die Übersicht bietet den Schnellfilter „Meine Datasets". Verliert die Person ihre Berechtigung, bleibt sie eingetragen und das Dataset trägt den Hinweis „Owner nicht mehr berechtigt".
Ruhigere Detailseite. Der gelbe Hinweis „Letzte Aktualisierung vor … Tagen" entfällt. Die Kopfzeile zeigt neben dem Datum neutral „vor N Tagen" und die Pflegeart.
Kopieren in eine andere Umgebung mit Beziehungen. Hat die Tabelle Spalten vom Typ „Verknüpfung", zeigt der Kopier-Dialog („In Umgebung kopieren…") den Abschnitt „Beziehungen". Eine Prüfung ohne Schreibzugriff zeigt vorab, woran jede Beziehung in der Zielumgebung gebunden wird: standardmäßig an die Tabelle mit demselben Namen, bei Selbstbezug an die Kopie selbst, oder an eine Tabelle, die Sie über „Andere Tabelle wählen…" auswählen. Solange eine Beziehung nicht gebunden werden kann, ist „Kopieren" gesperrt, und der Dialog nennt den Grund. Fehlen verknüpfte Tabellen in der Zielumgebung, kopiert „Fehlende Abhängigkeiten zuerst kopieren (n)" sie in der richtigen Reihenfolge als Entwurf (bei Land → Region → Kontinent zuerst Kontinent). Zirkelbezüge erkennt der Dialog und nennt eine Umgehung. Nach dem Kopieren sehen Sie, welche Beziehungen umgestellt wurden. Siehe Beziehungen beim Kopieren.
Mandanten umbenennen. Plattform-Admins ändern den Namen eines Mandanten im Tab „Tenants" der Plattform-Verwaltung im Abschnitt „Anzeigename" mit „Umbenennen". Der Name darf höchstens 200 Zeichen lang sein, und die Änderung steht im Änderungsprotokoll.
Microsoft Fabric je Umgebung. Unter Einstellungen → Integrationen → Microsoft Fabric richten Sie für jede Umgebung ein eigenes Ziel ein (Storage Account oder OneLake direkt). Oben auf der Seite zeigt eine Kontextzeile die Umgebung. Die Übersicht „Bereitstellung je Umgebung" zeigt Art, Ziel, Automatik und Status aller Umgebungen. Mit „Zu dieser Umgebung wechseln" springen Sie direkt in eine Umgebung.
Bestätigung bei der ersten Bereitstellung aus einer Nicht-Live-Umgebung. Der Dialog „Bereitstellung in einer Nicht-Live-Umgebung aktivieren?" weist darauf hin, dass Daten der Umgebung an ein externes System gehen. MDM Lite hält die Bestätigung im Änderungsprotokoll fest.
Zielschutz. Zwei Umgebungen können nicht in dieselben Tabellenordner schreiben. MDM Lite prüft das beim Speichern (409, integration_target_in_use) und lässt keine Tabelle eines anderen Datasets überschreiben (delta_table_owned_by_other_dataset). Ein Lakehouse für mehrere Umgebungen ist mit nicht verschachtelten Pfad-Präfixen wie dev/, test/, prod/ möglich.
Zielwechsel. Ändern Sie das Ziel einer Umgebung, schreibt MDM Lite die Datasets bei der nächsten Bereitstellung ins neue Ziel. Die Tabellen im alten Ziel bleiben bestehen.
Microsoft Purview je Umgebung. Jede Umgebung bekommt eine eigene Purview-Konfiguration mit eigenem Service Principal, eigenem Webhook-Secret und optionaler Collection. Veröffentlichen, Jetzt synchronisieren, automatische Wiederholungen nach Fehlern und die Lineage aus erzeugten Notebooks arbeiten in jeder Umgebung, jeweils mit der Konfiguration dieser Umgebung. Neue Assets einer Umgebung außer Live tragen den Umgebungs-Slug im Schlüssel, damit sie im Katalog unterscheidbar sind. Der Rücklink im Asset öffnet das Dataset in seiner Umgebung.
Je Umgebung konfigurierbar: KI-Zugriff (MCP) mit dem Endpunkt /mcp/{Umgebungs-Slug}, Notebook-Erzeugung und API-Keys. Siehe Integrationen und Umgebungen.
Berechnete Spalten. Eine Spalte lässt sich aus 2 bis 10 anderen Spalten derselben Tabelle zusammensetzen, zum Beispiel aus Land, Segment und Jahr zu DE|Privat|2026. Damit bilden Sie einen zusammengesetzten fachlichen Schlüssel ab: Markieren Sie die berechnete Spalte als Primärschlüssel, und auch der Import im Modus „Ergänzen & Aktualisieren" gleicht über diese Kombination ab, statt eine zweite Zeile anzulegen. Das Anlegen erfolgt im Tab „Spalten" über „Spalte hinzufügen" → „Berechnet aus anderen Spalten", mit Trennzeichen, optionaler Stellenzahl mit führenden Nullen und einer Vorschau. Die Werte sind schreibgeschützt und entstehen automatisch beim Speichern, bei Massenänderungen und beim Import. Eine Datei-Spalte mit gleichem Namen ignoriert der Import mit einer Warnung. Eine berechnete Spalte lässt sich jederzeit in eine normale Spalte umwandeln, und ihre Klassifizierung ist mindestens so hoch wie die ihrer Quellspalten. Berechnete Spalten gibt es nur in Tabellen. Siehe Berechnete Spalten.

Spalten gesammelt bearbeiten und verwerfen

Änderungen werden gesammelt und gemeinsam gespeichert. Im Tab „Spalten" klicken Sie auf „Spalten bearbeiten". Alle Änderungen, auch Typwechsel, Löschen, berechnete Spalten und die Übernahme von FK-Vorschlägen, werden zunächst nur im Bearbeitungsmodus vorgemerkt und mit „Speichern (+n ~n −n)" gemeinsam übernommen. Neue, geänderte und zum Löschen vorgemerkte Spalten sind markiert. Bisher wirkte jede Aktion sofort. „Fertig" entfällt.
„Verwerfen". Mit „Verwerfen" nehmen Sie alle noch nicht gespeicherten Änderungen zurück. Einzelne Spalten setzen Sie mit „Änderungen an dieser Spalte zurücknehmen" zurück.
Zusammenfassung vor dem Speichern. Der Dialog „Änderungen speichern" zeigt die entstehende Version, jede Änderung, die Auswirkung auf die Daten (Zeilenzahl, Datenverlust, nicht passende Werte) sowie Hinweise, zum Beispiel „Breaking Change" oder dass Beziehungen anderer Datasets bei einer Umbenennung automatisch mitgezogen werden. Nichts wird geschrieben, bevor Sie bestätigen.
Genau eine Version. Enthält der Speichervorgang mindestens eine strukturelle Änderung, entsteht eine neue Version für alle Änderungen zusammen, statt je Aktion eine. Reine Anzeige-Einstellungen (Bezeichnung, Breite, Sichtbarkeit, Klassifizierung, Glossar-Begriff, Reihenfolge) erzeugen keine Version. Gespeichert wird alles oder nichts.
Konflikte werden erkannt. Hat jemand anderes die Spalten inzwischen geändert, überschreibt MDM Lite diese Änderung nicht still. Sie laden den aktuellen Stand und behalten Ihre Änderungen oder verwerfen sie.
Schutz vor Verlust. Bei ungespeicherten Änderungen im Tab „Spalten" oder „Daten" fragt MDM Lite beim Wechsel des Tabs, beim Öffnen eines anderen Datasets oder Ordners (Seitenleiste, Befehlspalette, Fremdschlüssel-Link) und beim Schließen oder Neuladen der Seite nach. Die Zurück-Schaltfläche des Browsers ist davon ausgenommen.
Für API-Nutzer. Die Weboberfläche speichert über den neuen Endpunkt PATCH /api/datasets/{id}/schema (geordnete Operationen, ETag/If-Match, Vorab-Prüfung mit ?validateOnly=true). Die bisherigen Endpunkte je Spalte bleiben unverändert verfügbar. Siehe Änderungen sammeln und speichern.

Schema auf älteren Stand zurücksetzen

Spaltenstand einer älteren Version wiederherstellen. Bisher stellte „Als neue Version wiederherstellen“ nur die Daten wieder her. Eine versehentlich gelöschte Spalte kam nicht zurück. Jetzt setzt ein Admin des Datasets den Spaltenstand zurück: im Tab „Verlauf“ über „Schema auf Stand v{n} zurücksetzen…“, oder im Restore-Dialog über „Daten und Schema wiederherstellen…“. Es gibt zwei Umfänge: „Nur Schema – die aktuellen Daten bleiben“ und „Schema und Daten von Version #n“ (Spalten und Zeilen von damals).
Vorschau und bewusste Entscheidungen. MDM Lite zeigt vorher, welche Spalten wieder angelegt, entfernt oder angeglichen werden. Konflikte lösen Sie ausdrücklich: Eine Beziehung, deren Ziel fehlt oder archiviert ist, stellen Sie als Text-Spalte wieder her, verknüpfen sie mit einem anderen Dataset oder setzen die Spalte nicht zurück. Gehen beim Umfang „Nur Schema“ Werte entfernter Spalten verloren, bestätigen Sie das ausdrücklich. Ältere Versionen behalten die Werte.
Sicher für Historie und Klassifizierung. Das Zurücksetzen erzeugt immer eine neue Version und schreibt die Historie nie um. Die Klassifizierung einer Spalte wird dabei nie gesenkt. Die Version trägt im Verlauf das Badge „Schema aus v{n}“ bzw. „Daten und Schema aus v{n}“, das Änderungsprotokoll hält den Vorgang fest.
Auswirkung auf veröffentlichte Datasets. Ist das Dataset veröffentlicht und die neue Version gültig, wird sie sofort ausgeliefert. API, Export und Datenplattform zeigen dann den geänderten Spaltenstand. Die Vorschau weist darauf hin.
Grenzen. Nur für Tabellen (nicht Bäume) und nur für Versionen mit gespeichertem Spaltenstand. Nicht über API-Keys und nicht über MCP auslösbar. Siehe Schema auf älteren Stand zurücksetzen.

Verbessert

Deaktivierte Umgebungen liefern weiter und ziehen Spalten oberhalb der höchsten Klassifizierung weiterhin von der Datenplattform zurück.
Umgebung löschen: Der Dialog nennt die Zahl der mitgelöschten Integrationen und weist darauf hin, dass Tabellen auf der Datenplattform bestehen bleiben.
Bestätigung der höchsten Klassifizierung nennt, auf wie viele Bereitstellungsziele in wie vielen Umgebungen die Änderung wirkt.
Veröffentlichen-Dialog zeigt die Übertragung an die Datenplattform. Der Dialog nennt unter „Datenplattform", ob das Dataset nach dem Veröffentlichen automatisch übertragen wird oder ob Sie es manuell über „Jetzt synchronisieren" übertragen. Der Hinweis erscheint nur, wenn für die Umgebung ein Ziel eingerichtet ist; Mandanten-Admins finden darin einen Link zur Einstellung „Automatisch beim Veröffentlichen übertragen". Nach dem Veröffentlichen bestätigt eine Meldung den Vorgang, und das Plattform-Badge aktualisiert sich sofort. Siehe Veröffentlichen & Zurückziehen.
Reine Anzeige-Änderungen an einer Spalte erzeugen keine Version. Ändern Sie nur die Bezeichnung, Breite, Sichtbarkeit oder Reihenfolge einer Spalte, entsteht keine neue Version, auch nicht über den Einzel-Endpunkt der API (PUT /api/datasets/{id}/schema/columns/{columnId}). Das Änderungsprotokoll hält die Änderung weiterhin fest. Strukturelle Änderungen erzeugen wie bisher eine Version.
Änderungsprotokoll für gesammelte Schema-Änderungen. Das Protokoll zeigt „hat Schema-Änderungen gespeichert" mit der Zahl der Änderungen.
Fehlermeldungen in Ihrer Sprache. Die Oberfläche zeigt keine rohen englischen Server-Texte mehr, auch nicht im Veröffentlichen-Dialog, in den Import-Assistenten, im Datengitter, beim Speichern von Spalten und in Purview. Stattdessen erscheint eine verständliche, übersetzte Meldung.
Datenplattform: Datendateien, die ein abgebrochener Export in OneLake zurückgelassen hat und die zu keiner Version gehören, räumt MDM Lite nach der nächsten erfolgreichen Bereitstellung automatisch auf. Das geschieht nur im Tabellenordner des Datasets, nur für Dateien, die mindestens eine Stunde alt sind, und nur, wenn der Tabellenverlauf vollständig lesbar ist. Bereitgestellte Versionen bleiben unberührt.

Behoben

Beziehungen-Tab: Die Verbindungslinien folgen jetzt Änderungen der Fenstergröße und des Layouts und liegen nicht mehr neben den Karten. Der Tab beachtet die Einstellung „Archivierte Datasets anzeigen": Archivierte verknüpfte Datasets sind ausgeblendet, solange die Einstellung aus ist, und ein Hinweis nennt die Zahl der ausgeblendeten Beziehungen.
Rücklink aus Microsoft Purview: Der Link im Katalog-Asset öffnet das Dataset in der richtigen Umgebung. Ist die Umgebung unbekannt oder für Sie nicht zugänglich, bleiben Sie in Ihrer aktuellen Umgebung und sehen einen Hinweis. Die Übersicht der Purview-Konfigurationen aller Umgebungen lädt mit einem Aufruf.