Press "Enter" to skip to content

Category: DAX

Using REMOVEFILTERS in DAX UDFs

Marco Russo and Alberto Ferrari make use of REMOVEFILTERS:

A DAX user-defined function, also known as a UDF, is expected to return a scalar or a table. However, because functions are fundamentally macro-expansion of DAX code, it is possible to return CALCULATE modifiers if the function is to be called only as a filter argument of CALCULATE.

To show a practical example of when the feature proves to be useful, we debug a measure that fails because some calendar filters are not being removed correctly. Fixing the measure elegantly requires creating a function that removes filters rather than returning a value.

Click through for that example.

Leave a Comment

Optional Parameters in DAX UDFs

Marco Russo and Alberto Ferrari give us an option:

When Microsoft announced that DAX User-defined functions (UDFs) are generally available (GA), another new feature was also announced: it is now possible to define optional parameters in a function and assign them default values.

A parameter is optional when the caller can leave it out. In that case, the function still needs a value to work with, so it falls back to a default. DAX provides that default through an expression written directly in the function signature, next to the parameter it belongs to. This is the mechanism we describe in this article.

Read on to see how it works.

Leave a Comment

Removing Filters from the Filter Context in DAX

Marco Russo and Alberto Ferrari compare a few techniques:

Computing values in DAX is all about understanding how to manipulate the filter context to obtain the desired output. DAX offers a wide variety of functions to manipulate the filter context, including a rich set designed to remove filters. Among the many, four are used the most: ALLALLSELECTEDALLEXCEPT, and REMOVEFILTERS. Choosing the right one can be tough.

In this article, we do not want to dive into too many details; the goal is to let our readers understand when to use which function. Whenever needed, we provide links to deepen your knowledge about specific topics. Make sure to read the additional content if you want to know more about some specific behaviors.

Click through for demonstrations and a contrast of these different techniques.

Comments closed

DAX UDF Measures vs Calculation Groups for Time Intelligence

Bernat Agullo Rosello compares two capabilities:

Ever since DAX UDFs came out as public preview in September 2025, many DAX developers started wondering how they will compare with calculation groups since both have the centralization of code as one of their main selling points. As pointed out in a recent article by SQLBI they are indeed very different beasts, even though they can be used to achieve very similar outputs.

In short, a calculation group is a model-level object whose items swap one DAX expression for another at evaluation time. Once an item is in the filter context, it applies to every measure being evaluated. A DAX UDF is a smaller object: a named, reusable expression with parameters, callable from any measure but invisible to report users.

Read on to see when calculation groups still make sense and when DAX UDFs are the better choice.

Comments closed

User-Aware Calculated Columns in Power BI

Marco Russo and Alberto Ferrari show off something new:

A calculated column is computed when the table is refreshed and stored in the model (in Import mode), just like any other column, so its value does not depend on the user who is connected. The introduction of user-aware calculated columns in Power BI changes this picture because we can define a calculated column that is evaluated at query time and depends on the user running the query. This behavior can be obtained by setting the Expression Context property of a calculated column to User Context.

Click through to see the benefit of this new functionality.

Comments closed

Filtering DAX Measures through Slicers

Marco Russo and Alberto Ferrari provide a deeper answer:

A very common request by Power BI newbies is, “How can I use a slicer to filter a measure rather than a regular model column?” The most common answer to this question is, “You cannot filter a measure through a slicer”. The answer is entirely correct because there is no such thing as “filtering a measure”. However, elaborating on the why gives us a good way to explain not only what is wrong with the question, but also how to further reason about the requirements needed to obtain a working solution.

This blog post is an example of how challenging it can be to answer a beginner’s question, where the immediate answer is “No, you can’t do that” but the underlying problem is solvable.

Comments closed

Unmaterialized Columns in Power BI

Teo Lachev has ideal columns:

Coming back from a long vacation, I’ve almost missed this interesting Power BI enhancement: Power BI unmaterialized calculated columns. Normally, I avoid the traditional DAX calculated columns for a variety of reasons, such as confusion about where business logic is applied, limited support across storage modes (for example, Direct Lake doesn’t support them), longer refresh times, etc. This not to say that calculated columns can’t be useful, such as in the case where you need to flatten a parent-child hierarchy. But unmaterialized calculated columns could open interesting scenarios that go beyond content translation to other languages mentioned by Microsoft in the April 2026 update.

Click through to learn what unmaterialized columns are and how they work.

Comments closed

User-Context-Aware Calculated Columns in Power BI

Nikola Ilic digs into a new feature:

A few weeks ago, I was sitting in a session at FabCon Atlanta. It was an amazing session about Direct Lake semantic models and various optimization tips and tricks, delivered by true masters, Christian Wade and Phil Seamark (both from Microsoft). Among many fantastic topics, the one that immediately caught my attention was the new feature that Christian Wade introduced: User-context-aware calculated columns.

Although we all know that DAX calculated columns are the “last island” in what are considered recommended data modeling practices (“Roche’s Maxim”, etc.), this one still stood out for me as something that might be super useful in certain scenarios.

Read on to see how it works and scenarios in which it could be useful.

Comments closed

Parameter Types in DAX User-Defined Functions

Marco Russo and Alberto Ferrari talk about type systems:

In a previous article, Introducing user-defined functions in DAX, we described the syntax for creating user-defined functions, including the two passing modes (VAL and EXPR) and the fundamental parameter types SCALAR and TABLE. In this article, we build on that foundation and focus on the complete type system, with particular attention to the reference types introduced in March 2026 that provide better documentation, stronger validation, and improved IntelliSense support.

Before diving into the new types, let us briefly recap the full picture of parameter types and passing modes available in DAX user-defined functions.

Click through for a classic deep dive from Marco and Alberto.

Comments closed

Validating DAX against a Lakehouse via Semantic Link

Jens Vestergaard performs some checks:

A semantic model is a promise. It promises that the numbers in your reports match the data in your lakehouse. But after enough model changes, renamed columns, new relationships, and tweaked measures, that promise gets harder to verify. I wanted a way to check it programmatically.

This is my second submission to the Fabric Semantic Link Developer Experience Challenge. The first was a DAX unit test harness that compares measures against hardcoded expected values. That works well for known business rules, but it has a limitation: someone has to decide and maintain what the “right” answer is. For a model with hundreds of measures across dozens of filter contexts, that does not scale.

Click through to see what Jens did instead.

Comments closed