For years, DAX developers have faced a fundamental limitation when building large semantic models: the inability to encapsulate and reuse business logic.
While DAX is an extremely powerful analytical language, it has historically lacked one capability that software engineers take for granted in most programming languages: user-defined functions.
As a consequence, semantic models often contain hundreds or even thousands of measures that repeatedly implement the same patterns:
- Previous-period calculations
- Percentage change calculations
- Dynamic KPI indicators
- Custom formatting logic
- Time intelligence patterns
- Date range calculations
Although the business logic is identical, developers have traditionally been forced to duplicate the implementation for every measure.
The introduction of User-Defined Functions (UDFs) in DAX fundamentally changes this approach.
This article explores why UDFs matter, how they can improve semantic model architecture, and why they represent one of the most important maintainability improvements in DAX in recent years.
The Traditional DAX Problem
Consider a typical enterprise semantic model.
A business department wants to track:
- Revenue
- Orders
- Customers
- Claims
- Deliveries
- Tickets
For each metric, stakeholders usually request additional KPIs such as:
- Previous period
- Absolute change
- Percentage change
- Trend indicators
- Dynamic labels
A model with 100 business measures can easily grow to 400–500 measures.
Many of these measures differ only by the base metric they reference.
For example:
Revenue Previous Period
Orders Previous Period
Customers Previous Period
Claims Previous Period
The underlying logic is often identical.
Only the referenced measure changes.
This creates several challenges:
- Code Duplication: the same implementation exists dozens of times throughout the model.
- Maintenance Complexity: a small change in business logic may require updating many measures.
- Consistency Risks: different developers may implement slightly different versions of the same pattern.
- Technical Debt: over time, duplicated logic becomes difficult to identify and maintain.
These challenges become increasingly visible as semantic models grow in size and complexity.
Enter User-Defined Functions
User-Defined Functions allow developers to define reusable logic once and invoke it throughout the semantic model.
Instead of creating multiple versions of the same calculation, developers can encapsulate the logic in a single function.
Consider the following example:
FUNCTION Math.PctChange =
(
currentValue : NUMERIC,
previousValue : NUMERIC
)
=>
DIVIDE(
currentValue - previousValue,
previousValue
)
This function can now be reused throughout the model:
Math.PctChange(
[Revenue],
[Revenue Previous Period]
)
Math.PctChange(
[Orders],
[Orders Previous Period]
)
Math.PctChange(
[Customers],
[Customers Previous Period]
)
The implementation exists only once.
Building a Reusable Function Library
One of the most exciting aspects of UDFs is the possibility of establishing reusable function libraries.
In my current project, I started moving recurring patterns into dedicated namespaces.
Time Functions
Time.PreviousSelectedPeriod()
Time.SelectedPeriodText()
These functions encapsulate recurring time intelligence logic.
Mathematical Functions
Math.PctChange()
Math.GrowthRate()
Math.Ratio()
These functions provide reusable business calculations.
User Experience Functions
UX.ChangeIcon()
UX.FormatScaledValue()
UX.PreviousPeriodText()
These functions focus on KPI presentation and user-facing formatting.
The result is a semantic model where business measures become significantly easier to read.
Instead of embedding complex logic directly into measures, measures become small orchestration layers that consume reusable building blocks.
Why This Matters for Enterprise Models
The true value of UDFs becomes apparent in enterprise-scale semantic models.
In one of the projects I am currently involved in, the semantic model contains more than 400 measures.
Before UDFs, implementing a change to a recurring pattern could require reviewing dozens of measures.
With UDFs, the logic exists in one location.
Benefits include:
- Improved Maintainability: changes are implemented once and automatically inherited by all consumers.
- Better Governance: organizations can establish approved calculation patterns.
- Increased Consistency: business logic is implemented uniformly across the model.
- Faster Development: developers can focus on business requirements instead of repeatedly implementing infrastructure logic.
- Reduced Technical Debt: duplicated code is replaced by reusable abstractions.
A Shift in How We Think About DAX
The most important aspect of UDFs is not the reduction of code duplication.
The real transformation is architectural.
Historically, DAX development has been measure-centric.
Measures served simultaneously as:
- Business calculations
- Reusable components
- Presentation logic
- Utility functions
This often led to large, complex measure libraries.
UDFs introduce a separation of concerns.
Developers can now distinguish between:
- Reusable Functions: generic logic that can be used throughout the model.
- Business Measures: business-specific calculations built on top of reusable functions.
This is a familiar concept in software engineering and significantly improves model design.
Conclusion
User-Defined Functions do not introduce new analytical capabilities to DAX.
You could already implement the same calculations before.
What UDFs provide is something arguably more valuable: a mechanism for abstraction.
They allow developers to encapsulate business logic, eliminate duplication, improve maintainability, and build more scalable semantic models.
For small reports, the impact may be modest.
For enterprise semantic models containing hundreds of measures and multiple developers, the impact can be substantial.
In my view, User-Defined Functions represent one of the most significant improvements to DAX in recent years—not because they change what DAX can calculate, but because they fundamentally improve how we build and maintain semantic models.