DAX User-Defined Functions: Logik wiederverwenden

DAX User-Defined Functions, kurz DAX UDFs, sind seit Juni 2026 allgemein verfügbar. Für Power-BI-Teams ist daran weniger die neue Syntax interessant als ein grundlegender Modellierungsgewinn: Wiederkehrende Geschäftslogik kann im semantischen Modell zentral gekapselt und mit unterschiedlichen Eingaben wiederverwendet werden. Das reduziert Copy/Paste und kann Modelle wartbarer machen – wenn UDFs gezielt eingesetzt werden.

Das Wichtigste in 60 Sekunden

DAX User-Defined Functions sind selbst definierte, wiederverwendbare Funktionen für DAX-Logik im semantischen Modell. Sie eignen sich vor allem dann, wenn dieselbe fachliche Regel mehrfach mit unterschiedlichen Eingaben gebraucht wird.

Ein Measure bleibt dagegen das Modellobjekt für eine fachliche Kennzahl, die im Reporting ausgewertet wird. Eine UDF kapselt die gemeinsame Berechnungslogik, die mehrere Measures nutzen können. UDF und Measure sind deshalb kein Entweder-oder.

Eine UDF lohnt sich, wenn dieselbe fachliche Regel an mehreren Stellen identisch bleiben soll und sich die Unterschiede sauber über Parameter ausdrücken lassen. Für einmalige oder bewusst unabhängige Berechnungen ist ein normales Measure meist klarer.

Was sind DAX User-Defined Functions?

Eine DAX User-Defined Function ist eine vom Modellentwickler definierte Funktion, die wiederverwendbare DAX-Logik kapselt. Sie nimmt Eingaben entgegen und berechnet daraus ein Ergebnis. Damit ergänzt sie die eingebauten DAX-Funktionen um eigene fachliche oder technische Logik.

Wer zunächst die klassischen Bausteine auffrischen möchte, findet in unseren Top 10 DAX-Funktionen den Grundlagenkontext. UDFs setzen eine Ebene darüber an: Nicht eine weitere Standardfunktion steht im Mittelpunkt, sondern die Frage, wie eigene wiederkehrende Logik im Modell organisiert wird.

Der praktische Unterschied zeigt sich bei Änderungen. Wird dieselbe Formel an vielen Stellen kopiert, muss eine neue Geschäftsregel überall konsistent nachgezogen werden. Eine UDF schafft dagegen einen gemeinsamen Pflegepunkt.

Vorher: dieselbe Geschäftslogik mehrfach kopiert

Nehmen wir ein vereinfachtes Beispiel. Ein Unternehmen berechnet eine operative Marge in mehreren Bereichen nach derselben Grundlogik:

Marge Online =
DIVIDE(
    [Umsatz Online] - [Kosten Online],
    [Umsatz Online]
)

Marge Retail =
DIVIDE(
    [Umsatz Retail] - [Kosten Retail],
    [Umsatz Retail]
)

Bei zwei Measures ist das noch überschaubar. Problematisch wird es, wenn dieselbe Regel an zehn oder zwanzig Stellen vorkommt und später fachlich erweitert wird.

Dann entsteht nicht nur Pflegeaufwand. Es entsteht ein Governance-Risiko: Welche Variante verwendet noch die alte Regel? Wurden wirklich alle Stellen angepasst? Haben sich bereits leicht unterschiedliche Kopien entwickelt?

Nachher: die gemeinsame Regel als UDF kapseln

Mit einer UDF kann die Margenlogik einmal als gemeinsame Funktion im Modell definiert werden. Die Measures rufen anschließend dieselbe Regel mit ihren jeweiligen Eingaben auf. Das Nutzungsmuster lässt sich schematisch so darstellen:

Marge Online = Finance.Margin([Umsatz Online], [Kosten Online])
Marge Retail = Finance.Margin([Umsatz Retail], [Kosten Retail])

Finance.Margin steht hier bewusst für das Nutzungsmuster einer zentral definierten UDF. Es ist kein vollständiger Deklarationsblock zum Kopieren.

Entscheidend ist die Architektur: Die gemeinsame Margenlogik liegt nur noch an einer Stelle, während die Measures ihre jeweiligen Eingaben liefern.

Ändert sich die Geschäftsregel, wird die zentrale Funktion angepasst. Das reduziert die Zahl der Pflegepunkte. Gleichzeitig steigt aber die Reichweite dieser Änderung – deshalb gehören zentrale UDFs in einen sauberen Review- und Testprozess.

UDF oder Measure? Die wichtigste Entscheidung

UDFs ersetzen Measures nicht. In gut strukturierten semantischen Modellen ergänzen sie sich. Wer die grundlegende Unterscheidung von Modellobjekten vertiefen möchte, findet dazu unseren Vergleich Measures vs. Calculated Columns.

Die Länge einer Formel ist dabei kein gutes Kriterium. Eine lange Formel kann einmalig sein. Eine kurze Regel kann dagegen an fünfzehn Stellen wiederholt werden. Entscheidend sind gemeinsame Semantik und Wiederholungsbedarf.

Drei Designregeln für gute DAX UDFs

Kapselt stabile Regeln – nicht jede Hilfsformel

Eine UDF sollte eine klar benennbare Verantwortung haben, etwa eine einheitliche Verhältnisberechnung, eine Schwellenwertlogik oder eine wiederkehrende Transformation.

Wenn jede kleine Hilfsformel in eine eigene Funktion wandert, wird das Modell abstrakter, aber nicht automatisch verständlicher. Dann müssen Entwickler durch mehrere Ebenen springen, um eine einfache Kennzahl nachzuvollziehen.

Parameter müssen fachlich verständlich bleiben

Eine gute UDF macht über ihren Namen und ihre Eingaben klar, welche Regel sie kapselt. Ein Muster wie Finance.Margin(Umsatz, Kosten) ist fachlich leichter einzuordnen als eine generische Funktion mit nichtssagenden Parametern.

In größeren Modellen lohnt sich deshalb eine konsistente Benennung. Fachliche Namespaces oder eindeutige Präfixe können helfen, eigene Funktionen strukturiert zu organisieren.

Zentralisierung braucht Change Governance

Ein zentraler Pflegepunkt ist der größte Vorteil einer UDF – und gleichzeitig ihr wichtigstes Risiko. Eine Änderung kann mehrere Measures gleichzeitig beeinflussen.

Darum sollten zentrale Funktionen wie gemeinsam genutzte Modelllogik behandelt werden: Abhängigkeiten kennen, repräsentative Kennzahlen testen, fachliche Regressionen prüfen und Änderungen nachvollziehbar deployen.

Genau diese Verbindung von DAX und Modellarchitektur ist auch ein Kernpunkt unserer Five Pillars of DAX.

Wo DAX UDFs besonders viel bringen

Besonders interessant sind UDFs bei wiederkehrenden fachlichen Formeln über Regionen, Produkte, Szenarien oder Kennzahlen hinweg. Wenn sich die Unterschiede auf klar definierte Eingaben reduzieren lassen, ist die Logik ein guter Kandidat für Wiederverwendung.

Auch größere Teams profitieren. Je mehr Personen an einem Modell arbeiten, desto wichtiger werden gemeinsame Regeln. Eine UDF kann festlegen, wie eine bestimmte Berechnung umgesetzt wird, statt mehrere persönliche Varianten entstehen zu lassen.

Ein dritter Anwendungsfall ist das Refactoring gewachsener DAX-Landschaften. Wenn ihr mehrere nahezu identische Formeln findet, lohnt die fachliche Prüfung: Ist das wirklich dieselbe Regel? Wenn ja, kann eine UDF die Zahl der Pflegepunkte reduzieren.

Wo ihr besser bei Measures bleibt

Nicht jede ähnliche Formel sollte zusammengeführt werden. Zwei Berechnungen können technisch fast gleich aussehen und trotzdem unterschiedliche fachliche Bedeutungen haben. Werden sie vorschnell gekoppelt, entsteht eine Abhängigkeit, die fachlich gar nicht gewollt ist.

Auch Hilfs-Measures behalten ihre Berechtigung. Sie sind sinnvoll, wenn ein Zwischenergebnis als eigene Kennzahl sichtbar, separat testbar oder in vielen Kontexten direkt auswertbar sein soll. Eine UDF ist stärker auf die Wiederverwendung einer Regel ausgerichtet.

Copy/Paste ist ebenfalls nicht grundsätzlich verboten. Bei einer einmaligen, bewusst unabhängigen Logik kann eine direkte Formel die verständlichere Lösung sein. Problematisch wird Copy/Paste dort, wo die Kopien fachlich synchron bleiben müssen.

UDFs als Governance-Werkzeug im semantischen Modell

Der langfristige Nutzen liegt aus unserer Sicht vor allem in der Governance. In vielen Power-BI-Modellen entstehen Qualitätsprobleme nicht durch zu wenige Funktionen, sondern durch verstreute Varianten derselben Geschäftslogik.

UDFs schaffen dafür einen zusätzlichen Strukturbaustein: Eine gemeinsame Regel kann einen klaren Namen, definierte Eingaben, einen zentralen Pflegepunkt und eine erkennbare Verantwortlichkeit bekommen.

Das passt zur grundsätzlichen Rolle eines semantischen Modells in Power BI: Geschäftslogik, Beziehungen, Measures, Sicherheit und Metadaten sollen eine konsistente fachliche Schicht bilden.

Wichtig bleibt der Scope. Eine DAX UDF verbessert Wiederverwendung innerhalb des jeweiligen semantischen Modells. Sie ist kein unternehmensweiter Business-Rule-Service, der Regeln automatisch über mehrere Modelle, Datenplattformen oder Anwendungen verteilt.

Modellübergreifende Harmonisierung braucht weiterhin Architektur-, Deployment- und Governance-Mechanismen außerhalb der einzelnen Funktion.

Dasselbe gilt für Security. UDFs ersetzen nicht die Sicherheitsarchitektur des semantischen Modells. RLS, OLS und Berechtigungen bleiben eigenständige Modell- und Governance-Themen; aus dem Einsatz einer UDF sollte kein anderes Sicherheitsverhalten abgeleitet werden.

Ein pragmatischer Refactoring-Workflow

Wenn ihr UDFs in einem bestehenden Modell einführen wollt, startet nicht mit einer großen Funktionsbibliothek. Startet mit realer Wiederholung.

1. Sucht nach Measures oder Ausdrücken mit deutlich ähnlicher Logik.

2. Prüft fachlich, ob wirklich dieselbe Geschäftsregel dahintersteht.

3. Identifiziert die Teile, die variieren, als potenzielle Parameter.

4. Kapselt zunächst nur eine klar abgegrenzte Regel.

5. Testet die abhängigen Measures gegen den bisherigen fachlichen Output.

6. Dokumentiert Zweck, Eingaben und Verantwortlichkeit.

7. Erst danach entscheidet ihr, welche weiteren Muster sinnvoll abstrahiert werden.

Gerade bei komplexerem Filterverhalten lohnt parallel ein solides DAX-Verständnis. Unser Artikel zu Expanded Tables in DAX zeigt, warum Modellstruktur und Filterkontext häufig entscheidender sind als die reine Formel.

Ein Entscheidungsraster für bestehende DAX-Logik

Ob eine Formel ein guter UDF-Kandidat ist, lässt sich mit vier Fragen deutlich besser beurteilen als über ihre Länge oder technische Komplexität. Gerade in gewachsenen Modellen verhindert dieses Raster, dass aus einem sinnvollen Refactoring eine zusätzliche Abstraktionsschicht ohne echten Nutzen wird.

• Ist die fachliche Regel wirklich identisch? Zwei Formeln können ähnlich aussehen und trotzdem unterschiedliche Geschäftsregeln abbilden. Nur wenn die Semantik gleich bleiben soll, ist Zentralisierung sinnvoll.

• Ändern sich nur die Eingaben? Wenn Umsatz, Kosten, Schwellenwerte oder andere Eingaben variieren, die Berechnungsregel selbst aber stabil bleibt, spricht das für eine parametrisierte Funktion.

• Muss die Regel an mehreren Stellen synchron bleiben? Je größer der Schaden wäre, wenn eine Kopie vergessen wird, desto stärker ist der Nutzen eines zentralen Pflegepunkts.

• Kann das Team die Funktion fachlich benennen? Ein klarer Name ist ein guter Test. Wenn sich Zweck und Parameter nur technisch erklären lassen, ist die Abstraktion möglicherweise noch nicht reif.

Das Entscheidungsraster macht auch deutlich, wann eine UDF bewusst nicht die richtige Lösung ist. Eine einmalige Kennzahl, ein fachlich eigenständiger Sonderfall oder eine Berechnung, die sich künftig unabhängig entwickeln soll, bleibt als Measure oft verständlicher. Entscheidend ist nicht maximale Wiederverwendung, sondern eine Modellstruktur, in der gemeinsame Regeln tatsächlich gemeinsam und unabhängige Regeln tatsächlich unabhängig bleiben.

Was sich im Entwicklungsprozess mit zentraler Logik ändert

Mit UDFs verändert sich nicht nur die Ablage von DAX-Code, sondern auch die Verantwortung für Änderungen. Sobald mehrere Measures dieselbe Funktion verwenden, wird aus einer lokalen Formeländerung eine Änderung an gemeinsam genutzter Modelllogik. Das sollte sich im Entwicklungsprozess widerspiegeln.

Vor einer Anpassung sollte deshalb klar sein, welche Measures von der Funktion abhängen und welche fachlichen Szenarien repräsentativ getestet werden müssen. Bei einer Margenfunktion reicht es zum Beispiel nicht, nur einen Standardfall zu prüfen. Nullwerte, negative Werte, Sonderkosten oder abweichende Filterkontexte können Auswirkungen sichtbar machen, die bei einer einzelnen Measure-Formel leicht übersehen werden.

Für Teams lohnt sich zudem eine einfache Ownership-Regel: Wer darf zentrale Funktionen ändern, wie werden Änderungen dokumentiert und welche Kennzahlen dienen als Regressionstest? Dafür braucht es keinen schweren Governance-Prozess. Schon ein klarer Review-Schritt und einige definierte Testfälle verhindern, dass der Vorteil der Zentralisierung durch unkontrollierte Änderungen wieder verloren geht.

Damit wird UDF-Governance sehr konkret: Eine Funktion ist kein Selbstzweck, sondern ein gemeinsam genutztes Modellobjekt mit Auswirkungen auf mehrere Verbraucher. Je größer diese Reichweite ist, desto wichtiger werden nachvollziehbare Änderungen, Tests und ein kontrolliertes Deployment.

---

Fazit

DAX User-Defined Functions sind vor allem dann wertvoll, wenn Power-BI-Modelle wachsen und dieselbe Geschäftslogik an mehreren Stellen konsistent bleiben muss. Sie reduzieren Copy/Paste, schaffen einen zentralen Pflegepunkt und können Wartbarkeit sowie Governance verbessern.

Der richtige Einsatz ist selektiv. Measures bleiben die erste Wahl für eigenständige Kennzahlen. UDFs sind die bessere Wahl für stabile, wiederkehrende und sauber parametrisierbare Logik.

Wer diese Trennung beibehält, gewinnt Wiederverwendung, ohne das semantische Modell unnötig zu abstrahieren.

---

Der nächste sinnvolle Schritt

Wenn in euren Power-BI-Modellen DAX-Logik gewachsen ist, Measures schwer wartbar werden oder ihr gemeinsame Modellierungsstandards etablieren wollt, können wir im Power BI Coaching gemeinsam prüfen, welche Logik als Measure bleiben sollte, welche sich für UDFs eignet und wie ihr Änderungen sauber testet und dokumentiert.