Cascade Delete in Dynamics 365 finden

Ein Anwender löscht eine Firma die doppelt angelegt war. Der Dialog fragt einmal nach und dann ist sie weg. Was der Dialog nicht sagt: Mit der Firma verschwinden womöglich auch Aktivitäten, Verträge oder Servicefälle die an ihr hängen. Ob das passiert entscheidet eine Einstellung an der Beziehung die beim Anlegen oft niemand so ganz bewusst wählt.

Was beim Löschen mit den abhängigen Datensätzen passiert

Jede 1:N-Beziehung in Dataverse legt fest was mit den untergeordneten Datensätzen geschieht wenn der übergeordnete gelöscht wird. Für das Löschen gibt es genau drei Möglichkeiten (Microsoft Learn: Configure table relationship cascading behavior):

• Cascade: Die abhängigen Datensätze werden mitgelöscht.
• Remove Link: Die abhängigen Datensätze bleiben und ihr Verweis auf den gelöschten Datensatz wird geleert.
• Restrict: Der übergeordnete Datensatz lässt sich nicht löschen solange noch abhängige Datensätze existieren.

In Microsofts Dokumentation heißen die Grundmuster "Parental" (alles kaskadiert) und "Referential" mit "Remove Link" oder "Restrict Delete" (Microsoft Learn: Beziehungen zwischen Tabellen). Wer eine Beziehung als "Parental" anlegt bekommt das kaskadierende Löschen also gleich mit ohne es einzeln ausgewählt zu haben.

Warum das Risiko größer ist als es aussieht

Kaskaden setzen sich fort. Hängt an einem Vertrag wiederum eine Tabelle mit Vertragspositionen, ebenfalls mit "Cascade", dann löscht das Entfernen einer Firma den ganzen Baum darunter. Ein einzelner Klick erreicht damit Tabellen an die beim Löschen niemand gedacht hat.

Dazu kommt das Löschrecht. Ein Anwender mit organisationsweitem Löschrecht auf Firmen kann jede Firma entfernen und löst damit jedes Mal die Kaskade aus. Besonders heikel sind Massenlöschungen etwa beim Aufräumen alter Firmen oder Dubletten. Dort wird aus einem falsch gesetzten Filter schnell ein großer Datenverlust.

Rückgängig machen lässt sich das nur, wenn in der Umgebung das Aufbewahren gelöschter Datensätze eingeschaltet ist. Dann lassen sich gelöschte Datensätze eine einstellbare Zeit lang wiederherstellen (auch die per Kaskade gelöschten) aber nur in der richtigen Reihenfolge: erst der ursprüngliche Datensatz und danach die abhängigen (Microsoft Learn: Restore deleted Dataverse table records). Ist die Einstellung aus bleibt nur die Sicherung der ganzen Umgebung.

Wann "Cascade" richtig ist

Kaskadierendes Löschen ist kein Fehler. Denn es passt dort gut, wo die abhängigen Datensätze ohne den übergeordneten keinen Sinn haben (z.B. Positionen eines Auftrags etwa oder Antworten eines Fragebogens). Verschwindet der Auftrag will niemand verwaiste Positionen behalten.

Es passt nicht, wenn die abhängigen Datensätze eigenen Wert haben. Verträge oder z.b. Rechnungen sind nach wie vor wichtig. Sie gehören zu einer Firma und dennoch müssen sie existieren obwohl die Firma nicht im System bleibt. Genau an solchen Beziehungen steht "Cascade" häufig nur deshalb, weil beim Anlegen "Parental" gewählt wurde.

Die Alternativen

Restrict ist die vorsichtigste Wahl. Der übergeordnete Datensatz lässt sich erst löschen wenn die abhängigen bewusst entfernt oder umgehängt sind. Das zwingt zu einer Entscheidung und verhindert das stille Mitlöschen. Der Preis: Prozesse und Schnittstellen die heute übergeordnete Datensätze löschen laufen danach in einen Fehler. Das muss man vor der Umstellung wissen.

Remove Link lässt die abhängigen Datensätze stehen und leert nur den Verweis. Das schützt die Daten, hinterlässt aber Datensätze ohne eine Zuordnung. Für Belege mit Aufbewahrungspflicht ist das trotzdem oft besser als ein Verlust.

Deaktivieren statt Löschen ist meistens die eigentliche Antwort. Eine Firma die nicht mehr gebraucht wird lässt sich deaktivieren. Ihre Historie bleibt und gelöscht wird nur nach einem Löschkonzept. Wie das mit Datenschutzpflichten zusammenspielt beschreibe ich unter Datenschutz in Dynamics 365 Anpassungen. Die Alternative zum Löschen wäre eine Zusammenführung mit der Duplette. Hier werden relevante Datensätze umgezogen und behalten Bestand.

Wie man riskante Kaskaden findet

In der Oberfläche steht das Verhalten an jeder Beziehung einzeln verteilt über alle Tabellen. Für eine Bestandsaufnahme ist das mühsam und muss für jede Tabelle unter den Beziehungen manuell geprüft werden. Der Lösungsexport enthält dagegen alle Beziehungen mit ihrem Löschverhalten auf einmal.

D365 Audit wertet dieses Verhalten mit unterschiedlichen Regeln aus. Jeder Treffer ist eine Frage an den Fachbereich und kein automatischer Fehler: Sollen diese Datensätze wirklich mit verschwinden? Wo die Antwort nein lautet ist "Restrict" oder "Remove Link" die Änderung, ergänzt um eine Regel zum Deaktivieren. Weitere Muster dieser Art stehen unter Sicherheitsprobleme in Dynamics 365 Lösungen.