Nicht verwendete Felder identifizieren
Felder verschwinden nie von selbst. Wie man Kandidaten für ungenutzte Felder findet und welche Prüfungen vor dem Entfernen wirklich zählen.
Eine Tabelle mit 200 Feldern, von denen die Hälfte niemand mehr zuordnen kann: Das ist keine Übertreibung, sondern oftmals der Normalzustand nach ein paar Jahren Betrieb. Felder werden angelegt wenn jemand sie braucht und bleiben wenn niemand mehr fragt. Die Frage ist, wie man die Spreu vom Weizen trennt ohne dabei etwas zu zerstören.
Schritt eins: die Verwendung in der Konfiguration
Der Solution-Export beantwortet die erste Runde von Fragen vollständig. Für jedes Feld lässt sich prüfen ob es auf einem Formular platziert ist. Das steht in den Formulardefinitionen. Ob eine Ansicht es anzeigt oder danach filtert steht im fetchxml der Ansichten. Außerdem sieht man ob eine Business Rule oder ein Workflow es liest oder schreibt bzw. ob ein JavaScript seinen Namen erwähnt.
Ein Feld welches in keiner dieser Quellen auftaucht, ist ein Kandidat für eine Bereinigung. Nicht mehr aber auch nicht weniger: Bei einer typischen gewachsenen Tabelle bleibt so von 200 Feldern eine Kandidatenliste von vielleicht 50 übrig. Nur über diese muss überhaupt gesprochen werden.
Schritt zwei: was der Export nicht weiß
Jetzt kommen die Nutzungen die in keiner Solution stehen. Ein Feld kann von einer Integration befüllt werden, in einem Power-BI-Bericht auftauchen, in einem Flow einer ganz anderen Lösung gelesen werden oder in einer Marketingliste als Filter dienen.
Zwei Prüfungen decken das meiste davon ab. Die Abhängigkeitsanzeige der Plattform listet was innerhalb von Dataverse auf das Feld zeigt auch über Lösungsgrenzen hinweg. Man findet sie an der Komponente unter Abhängigkeiten anzeigen. Und eine einfache Abfrage zählt in wie vielen Datensätzen das Feld überhaupt einen Wert hat. Ein Feld ohne Konfigurations-Verwendung ohne Abhängigkeiten und ohne einen einzigen befüllten Datensatz ist so tot wie es aus der Ferne feststellbar ist.
Bleibt der Rest: externe Systeme, die per API lesen. Die sieht keine der Prüfungen. Deshalb gehört zu jeder Löschliste die Rückfrage an die Kollegen, die die Schnittstellen betreuen.
Schritt drei: entfernen mit Rückweg
Auch nach aller Prüfung empfiehlt sich ein Zwischenschritt statt des direkten Löschens. Das Feld von den Formularen nehmen und aus den Ansichten, den Anzeigenamen um einen Hinweis ergänzen, und dann warten. Ein Quartal ist ein guter Zeitraum: lang genug für Monats- und Quartalsprozesse, die das Feld vielleicht doch brauchen.
Erst danach kommt das Löschen (und zwar bewusst einzeln statt in einer großen Sammelaktion). Wenn doch etwas bricht will man wissen welches Feld es war.
Der eigentliche Gewinn
Es geht bei dieser Übung nicht um Speicherplatz. Jedes Feld, das bleibt muss bei jeder künftigen Änderung mitgedacht, mitgetestet und mitdokumentiert werden. Darum geht es. Eine Tabelle welche von zweihundert auf hundertsechzig Felder schrumpft ist bei jedem weiteren Umbau spürbar billiger. Das ist der Zins den diese Arbeit abwirft, und er kommt jedes Jahr wieder.
Laden Sie Ihren Solution-Export hoch und erhalten Sie in Minuten eine Auswertung: Sicherheitsrisiken, technische Schulden, Dokumentationsgrad und Migrationsrisiko. Kein Zugriff auf Ihre Umgebung nötig, erste Kennzahlen kostenlos.
Lösung analysieren Beispielreport ansehen