D365 Audit
Blog · 2026-08-22 · 5 min read
This article is currently available in German only. An English version may follow.

Welche Komponenten verursachen schlechte Performance?

Nicht alle Anpassungen kosten gleich viel. Eine Rangliste der Komponententypen, die Dataverse-Umgebungen in der Praxis am stärksten ausbremsen.

Formulare habe ich in einem eigenen Artikel behandelt denn dort sitzt die "gefühlte Langsamkeit". Die gemessene Langsamkeit einer Umgebung, also träge Speichervorgänge, hakende Importe, zähe Listen, hat andere Verursacher. Eine Rangliste nach Schadenspotenzial.

Platz eins: synchrone Plug-ins im Speicherpfad

Ein synchrones Plug-in welches auf Erstellen oder Aktualisieren hört läuft mitten in der Transaktion. Der Nutzer wartet beim Klick bis das Plug-in fertig ist und ein Datenimport wartet bei jedem einzelnen Datensatz darauf. Zwei oder drei solcher Schritte hintereinander, womöglich mit eigenen Datenzugriffen (oder dem Aufruf eines Webservices darin) und aus einem Speichern werden Sekunden, aus einem Import Stunden.

Der Befund kommt aus dem Export: die Registrierungen mit Nachricht, Stufe und Ausführungsmodus. Die Frage an jeden synchronen Schritt lautet, ob das Ergebnis wirklich sofort in derselben Transaktion vorliegen muss. Erstaunlich oft lautet die ehrliche Antwort "nein" und mit einer Umstellunt auf asynchrones Verhalten wäre der Nutzer die Wartezeit los.

Platz zwei: Registrierungen auf Abrufnachrichten

Plug-ins auf RetrieveMultiple der großen Tabellen laufen bei jeder Listenansicht, jeder Suche und jedem Untergitter mit. Ein einziges solches Plug-in kann eine ganze Umgebung träge wirken lassen weil es an hundert Stellen gleichzeitig mitläuft. Solche Registrierungen sind selten, aber wenn sie da sind, gehören sie ganz nach oben auf die Liste.

Platz drei: Automatisierungs-Ketten

Ein Workflow aktualisiert einen Datensatz und das löst den nächsten Prozess aus, welcher wiederum schreibt. Einzeln ist jeder Schritt harmlos. Als Kette erzeugen sie Lastspitzen und gelegentlich Schleifen, die erst der Plattform-Schutz abbricht. Im Export der Lösung werden sie sichtbar über die Trigger: Wenn mehrere Prozesse auf dieselbe Tabelle bei denselben Feldern reagieren und selbst wieder zurückschreibe ist eine Kette mindestens möglich bzw. wahrscheinlich.

Platz vier: Audit mit der Gießkanne

Die Überwachung ist pro Feld eine Kleinigkeit und durchaus sinnvoll. Flächendeckend aktiviert, auf jeder Tabelle und jedem Feld, schreibt sie bei jeder Änderung mit und lässt die Protokolltabelle auf Größen wachsen, welche Speicherkosten und Wartung belasten. Die Einstellung steht pro Tabelle und pro Feld im Export und lässt sich auswerten. Gemeint war meistens: die 10 wichtigsten Felder überwachen. Konfiguriert wurde: alle.

Platz fünf: Rollup-Felder in Zahl

Rollup-Felder berechnen sich über Systemjobs neu und das standardmäßig im Stundentakt. Ein paar davon sind unproblematisch. Dutzende auf großen Tabellen erzeugen dauerhafte Hintergrundlast und ihre Werte sind trotzdem nie ganz aktuell, was regelmäßig zu Supportfragen führt.

Die Blickrichtung

Auffällig an dieser Liste: Nichts davon ist ein exotischer Fehler. Es sind normale Werkzeuge in zu großer Dosis oder am falschen Ort. Deshalb funktioniert die Prüfung auch als Mengengerüst aus dem Export ganz ohne Laufzeitmessung: Anzahl synchroner Schritte, Abruf-Registrierungen, Trigger-Überschneidungen, Audit-Quote, Rollup-Bestand. Welche Bauarten schon vor dem Produktivstart erkennbar sind, steht unter Performance-Risiken früh erkennen. Wo die Zahlen aus dem Rahmen fallen lohnt sich die Messung. Wo nicht, kann man sich die Messung meist sparen.

Wie steht Ihre eigene Lösung da?

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