DAX User-Defined Functions in Power BI - First Impressions From the Preview

If you've ever copy-pasted the same DAX formula across four measures with slight tweaks, you'll understand why I got a bit excited when Microsoft put DAX user-defined functions into preview. We've all been writing the same defensive boilerplate for years. Same calculation pattern, slightly different table, slightly different filter context, paste it again, change one variable, hope you didn't miss anything.

UDFs are Microsoft's attempt to fix that. The basic pitch is simple. Define a calculation once, give it parameters, then call it everywhere. They live inside the model as proper first-class objects, not measure hacks or comment-blocked snippets you've copied between files.

I've been running them on a couple of client projects since they landed in preview. Here's the honest assessment. They fix a real problem, they're rougher than I'd like, and there are a few things you should know before you commit to using them in production work.

What problem do they actually solve

Take any reasonably sized Power BI semantic model. Open the measures. I guarantee you'll find at least three places where someone has written the same logic with minor variations. Tax calculations are a classic. Margin calculations. Time intelligence patterns. Currency conversions. Anywhere you've got a piece of business logic that needs to be applied to different inputs, you end up duplicating the formula.

This isn't laziness. DAX didn't have a clean way to share logic without scope. Variables are local to a single expression. Measures evaluate in their own filter context. Calculated tables and columns are static. If you wanted reusable parameterised logic, your only real option was to write longer and longer measures with increasing complexity, or to use calculation groups (which solve a different problem).

UDFs let you define something like this:

FUNCTION AddGST = (
        amount : NUMERIC
    ) =>
    amount * 1.1

Then call it from measures, calculated columns, visual calculations, anywhere DAX is supported. The function lives in the model, shows up in Model Explorer under a Functions node, and gets versioned alongside everything else.

The Microsoft documentation goes through the syntax in detail if you want the official reference, but the actual experience of writing one is straightforward if you've written DAX before.

The good stuff

Three things I genuinely like about how this has been implemented.

First, you get type hints. You can specify that a parameter must be NUMERIC, or INT64, or TABLE. When you call the function with the wrong type, you get an error rather than a silently nonsensical result. This is a big deal for anyone who has ever had a measure return a bizarre answer because someone passed in a text value that DAX implicitly converted.

Second, the integration with DAX Query View and TMDL view is decent. You can prototype a function in DQV, test it with EVALUATE, then save it to the model with a single click. The Update Model status line at the bottom of the query editor is genuinely useful. If you use TMDL view or work with Power BI Projects in source control, your functions get serialised to a functions.tmdl file in the definition folder. This means proper version control, proper code review, proper diff visibility. About time.

Third, you can nest them. Build a basic function for tax, build another for tax-and-discount that calls the first, and the inheritance just works. This sounds obvious but it's the difference between actual code reuse and another flavour of copy-paste.

Where it gets rough

The preview label is there for a reason. A few things to watch out for.

The error messages when something goes wrong with a UDF are not great. If you've made a syntax mistake in the function definition, the message tells you the function failed but often not exactly why. I've spent more time than I'd like staring at "An argument of function 'AddGST' has the wrong type or invalid value" trying to work out which argument. This will improve, but for now it slows down the iteration loop.

Performance is not always what you'd hope. Most of the time UDFs are fine, but I've seen cases where wrapping a measure in a UDF produced slower execution plans than the inlined version. Not by huge margins, but enough to matter on big models. If you're working with semantic models that hit the limit on Premium capacity, profile before and after.

There's no good story yet for shared UDFs across multiple models. Each model has its own copy. If you have a standard set of business calculations that should apply across ten semantic models, you still need to manage that consistency yourself. Microsoft is hinting at shared libraries but nothing concrete yet.

And the preview feature gate means you have to turn it on in Options. This is a small thing, but it does mean that anyone opening your PBIX file without the preview feature enabled will see errors. For solo work this is fine. For team work, make sure everyone is on the same page about preview features before you adopt this widely.

When I'd use UDFs today

Real talk on where they earn their keep right now.

Repeated calculations across measures. If you've got the same pattern showing up in five or more measures, that's a candidate. Build the UDF, refactor the measures to call it, and your model gets noticeably cleaner. This is the obvious win.

Type safety on dodgy inputs. When you're pulling data from sources where you can't fully trust the types, UDFs with explicit type hints add a layer of validation that's hard to do otherwise. We've used this on a financial reporting model where some columns came in as text because the source CSV had mixed values. The UDF approach made it possible to enforce type expectations without rewriting the upstream pipeline.

Building reusable libraries inside one model. If you've got a semantic model that's owned by a team and used by many report authors, UDFs let you give those report authors a vocabulary of standard calculations. Total Sales with Tax. Customer Lifetime Value. Average Order Value. These are business concepts your team should agree on once, then everyone uses the same function. This is the use case I'm most excited about.

For our Power BI consulting work, this is starting to change how I recommend modelling business logic in mature deployments. The pattern of "one team owns the model, lots of teams build reports" finally has a clean way to ship consistent calculations.

When I'd still skip them

A few situations where I'm holding off.

Anything that needs to ship to production this quarter where you can't tolerate preview-feature surprises. Microsoft sometimes changes preview behaviour between releases. If your model needs to survive a Power BI update without manual intervention, wait for general availability.

Models with strict performance budgets. Until I can be confident that UDFs don't regress query plans, I'm sticking with inlined measures for anything that runs in critical paths. Performance regressions can be subtle and only show up under specific filter combinations.

Models where the team isn't comfortable with DAX. UDFs add a level of abstraction. If your team is still building basic measures, adding parameterised functions on top can make the model harder for newer people to understand. Walk before you run.

Getting started

If you want to try them out, turn on the preview feature in File > Options and settings > Options > Preview features and restart Power BI Desktop. Then either use DAX Query View to define them inline:

DEFINE
    /// Adds GST to an amount
    FUNCTION AddGST = (
            amount : NUMERIC
        ) =>
        amount * 1.1

EVALUATE
{ AddGST ( 100 ) }

Or use TMDL view if you prefer the script-based approach. Either way, Model Explorer is where you go to see and manage what you've defined. The Microsoft documentation on DAX user-defined functions has the syntax reference if you want to go deeper.

A note on team adoption

If you're rolling this out to a team of analysts, set some conventions early. Naming, parameter types, where descriptions go. Without conventions you'll end up with addtax, AddTax, add_gst, and CalculateGSTOnAmount all in the same model, which defeats the purpose. The /// comment above each function definition shows up in IntelliSense, so use it to document what the function does and what its parameters expect.

Also have a chat about who owns the function library inside a model. UDFs are easy to add, easy to modify, and easy to break things with if multiple people are changing them without coordination. The same governance considerations that apply to shared measures apply here. Probably more so, because UDFs have wider blast radius when something changes.

My take

DAX UDFs are one of those features that should have existed years ago. The preview is good enough to use on real work, with the caveat that you should treat it as a preview. There are rough edges and you should expect some changes before GA.

For us, this is changing how we structure semantic models. The pattern of one model with a clean function library, consumed by many report authors, is finally practical. If you're running a Power BI deployment at any scale, it's worth getting familiar with these now so you're ready when the preview label comes off.

The Microsoft article on this preview feature is the official reference. Worth bookmarking.