Tote Komponenten in Dynamics 365 finden

Jede Lösung, die länger als zwei Jahre lebt, enthält Komponenten, die nichts mehr tun. Ein Feld, das aus keinem Formular mehr erreichbar ist. Ein Skript, bei dem kein Ereignis mehr aufgerufen wird. Ein Workflow, der seit Jahren deaktiviert ist. Zusammen machen sie eine Lösung unübersichtlich, ohne dass man jemanden direkt dafür verantwortlich machen könnte.

Die vier typischen Arten von Ballast

Verwaiste Web-Ressourcen. Ein JavaScript liegt in der Lösung, wird aber in keinem Formular und keinem Ribbon referenziert. Das ist der am einfachsten zu findende Fall, weil sich die Referenzen direkt aus den Lösung selbst auslesen lassen.

Ungenutzte Felder. Ein Feld existiert, taucht aber auf keinem Formular und in keiner Ansicht auf. Es kann trotzdem befüllt sein, etwa über eine Integration oder einen Flow. Hier ist vorsicht geboten, weil auch lesende Operationen wie z.B. aus PowerBi auf die Daten zugreifen können.

Deaktivierte Prozesse. Workflows und Flows, die auf inaktiv stehen. Manche wurden bewusst pausiert, andere sind Reste eines abgeschalteten Vorgehens. Von außen sieht beides gleich aus.

Doppelte Ansichten. Zwei Ansichten mit derselben Abfrage und unterschiedlichem Namen. Entsteht, wenn jemand eine bestehende Ansicht kopiert, statt sie anzupassen.

Warum Löschen schwerer ist, als es aussieht

Die entscheidende Einschränkung: Ein Solution-Export zeigt nur, was in dieser einen Lösung passiert. Eine Web-Ressource, die hier von keinem Formular referenziert wird, kann von einer anderen Lösung in derselben Umgebung genutzt werden.

Das gilt genauso für Felder. Sie werden vielleicht nicht im Formular angezeigt, aber von einem Flow beschrieben, von einem Bericht ausgewertet oder von einer Schnittstelle befüllt. Nichts davon steht in der Lösung, in der das Feld definiert ist.

Deshalb ist die ehrliche Aussage nicht „diese Komponente ist tot“, sondern „diese Komponente wird innerhalb dieser Lösung nirgends referenziert“. Der Unterschied klingt akademisch, entscheidet aber darüber, ob man beim Löschen etwas kaputtmacht.

Ein pragmatisches Vorgehen

So würde ich es angehen.

Erst die Kandidaten aus der Lösung ermitteln: nicht referenzierte Web-Ressourcen, Felder ohne Formular- und Ansichtsverwendung, deaktivierte Prozesse sowie doppelte Ansichten.

Dann die Liste gegen das prüfen, was der Export nicht weiß. Für Felder heißt das ein Blick in die Datenbank: Enthält das Feld überhaupt Werte? Ein Feld ohne Formularverwendung und ohne einen einzigen befüllten Datensatz ist ein sehr sicherer Kandidat.

Und zuletzt: nicht sofort löschen, sondern deaktivieren oder umbenennen. Ein Feld, das man mit einem Display Namen Präfix wie "veraltet" versieht, verschwindet aus dem Alltag, bleibt aber wiederherstellbar. Wenn nach einem Quartal niemand etwas gemerkt hat, kann es weg.

Der Nutzen

Der offensichtliche Gewinn ist Übersicht. Der weniger offensichtliche: Jede entfernte Komponente ist eine, die bei künftigen Umbauten nicht mehr geprüft werden muss. Bei einer Migration oder einem größeren Refactoring zahlt sich das direkt aus, weil der Umfang der zu bewertenden Objekte kleiner wird.

Wichtig bleibt die Reihenfolge: erst messen, dann bewerten, dann entfernen. Wer mit dem Löschen anfängt, macht früher oder später etwas kaputt, das jemand anderes noch brauchte.