DAX User-Defined Functions — A Complete Guide for Power BI

What Are DAX User-Defined Functions?

DAX User-Defined Functions (UDFs) let you define a parameterized calculation once and reuse it across measures, calculated columns, visual calculations, and other UDFs — instead of copying the same expression into dozens of places and hoping they stay in sync. A UDF is a first-class model object, viewable under the Functions node in Model Explorer, alongside tables, measures, and relationships.

DAX previously offered no equivalent — Power Query had M-language custom functions for years, but DAX itself only gained this capability with the September 2025 preview release. UDFs reached general availability in Power BI Desktop and the Power BI Service with the June 2026 release, after months of community testing validated the feature for production use.

Because UDFs are first-class model objects with typed signatures and documentation, tools like Copilot can discover and invoke them more effectively — giving AI agents a trusted, well-defined API into your business logic rather than relying on inferred DAX expressions scattered across measures.

DAX UDF Syntax — DEFINE FUNCTION and Arrow Notation

A function is declared using the FUNCTION keyword, a parameter list in parentheses, and an arrow (=>) — sometimes called a “rocket” in other programming languages — separating the signature from the function body.

FUNCTION <FunctionName> = (
    [<ParameterName> [: [<ParameterType>] [<ParameterSubtype>] [<ParameterPassingMode>]] [= <DefaultExpression>], ...]
) => <FunctionBody>

A Working Example

DEFINE
/// AddTax takes in amount and returns amount including tax
FUNCTION AddTax = ( amount : NUMERIC ) => amount * 1.1

FUNCTION AddTaxAndDiscount = ( amount : NUMERIC, discount : NUMERIC ) =>
    AddTax ( amount - discount )

EVALUATE { AddTaxAndDiscount ( 10, 2 ) }
// Returns 8.8

Notice that AddTaxAndDiscount calls AddTax directly — UDFs can call other UDFs, allowing layered, modular calculations. Once saved to the model, you use a UDF exactly like a built-in DAX function, anywhere DAX is supported:

Sales Amount with Tax = CONVERT ( AddTax ( 'Sales'[Sales Amount] ), CURRENCY )

val vs expr — Eager vs Lazy Evaluation, Explained

This is the single most misunderstood concept in DAX UDFs, and the most common source of silently wrong results. Every parameter has a passing mode that controls when and how it is evaluated.

Why This Matters — A Failing Example

Consider a function meant to filter sales to specific billing document types:

FUNCTION FilterDocTypes = ( docTypeExpr : STRING ) =>
    CALCULATE ( [Sales Amount], 'Sales'[Document Type] = docTypeExpr )

Without a type hint, the parameter defaults to ANYVAL with passing mode VAL. The parameter arrives as a fixed value — it cannot further modify filter context inside the function. The CALCULATE effectively does nothing useful here because the value was already resolved before the function ran. To make context-sensitive logic actually work, change the parameter to use EXPR:

FUNCTION FilterDocTypes = ( docTypeExpr : SCALAR STRING EXPR ) =>
    CALCULATE ( [Sales Amount], 'Sales'[Document Type] = docTypeExpr )

Context Transition Inside UDFs — The Part Everyone Gets Wrong

Even with EXPR set correctly, there is a second trap: EXPR parameters do not automatically receive context transition inside an iterator, unlike a direct measure reference. This is the detail that separates a function written by a beginner from one written by someone who understands DAX deeply.

MEASUREREF is the only reference type that guarantees automatic context transition — because it restricts the parameter to an actual measure, and any measure reference implicitly invokes CALCULATE. With ANYREF, the caller could pass a measure, a column, or an arbitrary expression — the function author cannot assume context transition happens and must defensively wrap the parameter reference in an explicit CALCULATE.

// Defensive pattern — guarantees correct behavior regardless of what the caller passes
FUNCTION BestCustomers = ( metricExpr : ANYREF, n : INT64 ) =>
    TOPN ( n, VALUES ( Customer[CustomerName] ), CALCULATE ( metricExpr ) )

Type Hints — Type, Subtype, and Parameter Mode

Type hints are optional but strongly recommended. They follow the form ParameterName : Type Subtype ParameterMode and provide IntelliSense guidance, runtime type safety, and self-documenting call sites.

Value Types (Eager — VAL by default)

Expression / Reference Types (Lazy — always EXPR)

Type-Checking Helpers and Information Functions

Validate parameter types defensively inside a function body using built-in DAX type-checking functions, and use TABLEOF / NAMEOF with COLUMNREF or TABLEREF parameters:

FUNCTION SafeRatio = ( numerator : SCALAR DOUBLE, denominator : SCALAR DOUBLE ) =>
    IF ( denominator = 0, BLANK(), numerator / denominator )

FUNCTION CastToInt = ( x : SCALAR INT64 VAL ) => x
EVALUATE { CastToInt ( 3.4 ), CastToInt ( 3.5 ), CastToInt ( "5" ) }
// Returns 3, 4, 5 — automatic coercion based on declared subtype

TABLEOF returns the full table associated with a given column, measure, or calendar reference — useful when a function needs to operate on “whatever table this column belongs to” without hardcoding a table name. NAMEOF returns the name of a table, column, measure, or calendar as a text string, useful for runtime validation messages.

Dynamic Time Intelligence with UDFs

Dynamic time intelligence — letting a user pick “MTD,” “QTD,” or “YTD” from a slicer and having one measure respond correctly — is the canonical use case requiring EXPR. The function must evaluate its argument inside the current filter context at call time, not at the moment the function was defined.

DEFINE
FUNCTION GetPeriod = ( MI : ANYREF, periodType : SCALAR STRING ) =>
    SWITCH (
        TRUE(),
        periodType = "MTD", CALCULATE ( MI, DATESMTD ( 'Date'[Date] ) ),
        periodType = "QTD", CALCULATE ( MI, DATESQTD ( 'Date'[Date] ) ),
        periodType = "YTD", CALCULATE ( MI, DATESYTD ( 'Date'[Date] ) ),
        MI
    )

EVALUATE
SUMMARIZECOLUMNS (
    'Date'[Month],
    "Period Value", GetPeriod ( [Sales Amount], "QTD" )
)

MI uses ANYREF so it accepts any measure or expression dynamically, and the explicit CALCULATE wrapping ensures context transition happens regardless of what the caller passes — the defensive pattern from Section 04 applied directly to time intelligence.

Migrating Calculation Groups to UDFs — and When to Combine Them

UDFs and calculation groups solve overlapping but distinct problems, and the GA-era best practice is usually to combine them rather than replace one with the other.

The Combined Pattern — UDF Called Inside a Calculation Item

Rather than choosing one or the other, define the reusable logic as a UDF, then call that UDF from inside a calculation item using SELECTEDMEASURE() as the argument:

// Calculation item inside a "Period" calculation group
Period Value =
VAR _type = SELECTEDVALUE ( Period[Type] )
RETURN GetPeriod ( SELECTEDMEASURE(), _type )

This gives report authors the calculation-group experience — pick a measure, apply a period from a slicer — while the actual logic lives in one centrally maintained, parameterized, testable UDF rather than being duplicated across calculation items.

Migrating a Wall of Formatting Measures

The other dominant migration pattern is collapsing hundreds of duplicated formatting-string measures into one function:

// Before: dozens of near-identical measures, one per KPI
Revenue Status Color = IF ( [Revenue] >= [Revenue Target], "#16a34a", "#dc2626" )
Margin Status Color   = IF ( [Margin] >= [Margin Target], "#16a34a", "#dc2626" )
// ...repeated for every KPI in the model

// After: one function, called by every KPI
FUNCTION StatusColor = ( actual : SCALAR DOUBLE, target : SCALAR DOUBLE ) =>
    IF ( actual >= target, "#16a34a", "#dc2626" )

Revenue Status Color = StatusColor ( [Revenue], [Revenue Target] )
Margin Status Color   = StatusColor ( [Margin], [Margin Target] )

A model with 150 dynamically colored measures previously meant editing 150 places when a threshold rule changed. With the function pattern, that becomes one edit, validated once, propagated everywhere it is called.

Debugging UDFs with EVALUATE in DAX Query View

Test a UDF locally before it touches a single measure or report visual, using EVALUATE directly in DAX Query View. This is the fastest feedback loop available — no need to build a measure, drop it on a visual, and inspect the result.

DEFINE
FUNCTION PercentChange = ( newValue : NUMERIC, oldValue : NUMERIC ) =>
    DIVIDE ( newValue - oldValue, oldValue )

EVALUATE
{
    PercentChange ( 120, 100 ),
    PercentChange ( 80, 100 ),
    PercentChange ( 0, 0 )
}
// Returns 0.2, -0.2, BLANK()

Quick Queries in Model Explorer

Right-click a UDF under the Functions node in Model Explorer to access three Quick queries that generate boilerplate EVALUATE scripts automatically:

Inspecting UDFs Programmatically

Use INFO.USERDEFINEDFUNCTIONS() to query full metadata for every UDF in the model — names, descriptions, parameters, and type hints. This requires write permission and only returns functions actually saved to the model.

EVALUATE INFO.USERDEFINEDFUNCTIONS()

daxlib.org — A Community Library of Reusable Functions

daxlib.org is a free, open-source, model-independent repository of DAX user-defined functions, referenced directly by Microsoft documentation as a source of reusable, community-tested logic. Functions published there are written to be portable — not tied to any specific model’s table or column names — so they can be imported into any semantic model.

Rather than writing common patterns from scratch — percent change, weighted averages, ranking helpers, statistical functions — daxlib.org lets teams pull a tested implementation and adapt it, the same way a software engineer would reach for a well-maintained open-source package instead of reimplementing a sorting algorithm.

Current Limitations of DAX UDFs

FAQ — DAX User-Defined Functions

Official Resources — DAX UDF Documentation