My Presentations at the MS Summit and Portland UG

Evaluation contexts in Power BI DAX

I was in Seattle, USA in the last week of July participating in the Microsoft Business Applications Summit. I love attending conferences like this and it was a privilege to present on a few topics over 3 days.  One of the presentations I gave was on the topic “Evaluation contexts in Power BI/DAX“.

Evaluation contexts is one of the hardest things to master in DAX. It is not uncommon to think you know how evaluation contexts work only to find that you are completely stumped by a formula that is not doing what you expect. In this session I explained the concepts of row context, filter context and context transition using on screen examples that anyone can understand.  Anyone with a working knowledge of DAX can learn from this session.

For those who missed the session, the recording is available now

DAX as a Query Language

As part of my visit to the USA, I was invited to attend the Pacific Northwest Power BI Symposium organised by Portland user group. In the symposium I presented on the topic “DAX as a Query Language“.

In this session, I introduced the topic and showed how one can use DAX Studio to connect to a data model.  Once connected, DAX studio can be used to write queries over the tabular data model to start to interrogate the data itself (as opposed to simply aggregating the values into a pivot table or a Power BI report).  The learning can then be used to write more complex DAX measures or alternatively it can be used to extract tabular data directly into a table for further analysis.

The session was live-streamed on YouTube, but for those who missed to view the presentation, it is available here.



  1. Hi Matt, I have watched your video from the Microsoft summit on Evaluation Context. I personally have never understood why the relationship endpoints are not part of the evaluation context. These endpoints or rather the changing of them has as much impact on the end result as the filter context or row context.

    An expression like CALCULATE([measure], CROSSFILTER(sales[productkey], product[productkey], none)) will change how the measure [measure] is filtered and corresponds to CALCULATE([measure], ALL(product)). When you make use of bidirectional filtering this becomes even more evident. Like in CALCULATE([measure], CROSSFILTER(sales[productkey], product[productkey], both))

    The setfilter arguments of CALCULATE will work together to create a new Evaluation context just before the first argument of CALCULATE is evaluated. DAX functions like CROSSFILTER and USERELATIONSHIPS are used in CALCULATE as setfilter arguments in line with ALL(), ALLSELECTED() , product[color]=”Red” etc.

    Some of the most basic of DAX is expanding a base table with rows from tables in the base table’s filter domain just before filtering a target table and the relationship endpoints are instrumental in and paramount to this.

    No one seems to include the endpoints in the evaluation context so it seems natural that you follow the same pattern. But why?

    Do you have any thoughts regarding this?

  2. Matt, That was great. When you watch a video and then think, “that makes total sense”, then it’s not that the content was simple, it is that the explanation was first class. Well done.

  3. There is a “join my newsletter” section on this page, and every blog page. If you are on a computer, it is top left. On a mobile device it is probabaly at the bottom end of the page.

Leave a Reply