Month: September 2015

My Thoughts on Cross Filtering in Power BI

My Thoughts on Cross Filtering in Power BI

September 30, 2015

It’s amazing how much of an influence your upbringing can have on you and your preferences. I was the youngest in my family for almost 10 years (till my brother came along) and not to say, growing up, I was very much pampered by my mom. However, my dad was more of a proponent of what I call tough love and back in those days, it was still legal to spank your child to set him straight. (Sometimes, I even feel like my father was the one who coined the proverb – Spare the rod and spoil the child). Looking back now, I feel those were the moments that really formed my character and helped me reach where I am, and I am really thankful to God almighty for giving me the perfect family. I know some of you might be nodding your head in agreement with me reading this post, while a lot of you might be getting really angry at what you are reading. This is perfectly understandable, and it’s ok, because we live in a free country, right? You might also be wondering the reason of such a lengthy introduction to my blog. Well, the reason is that today’s post is kind of tough love as I am criticizing (constructively) the way Cross Filtering works in Power BI, and also providing an example of how I think cross filtering should work in an efficient BI tool by showing Tableau as an example.

My thoughts on cross filtering in Power BI

Action Item – Please do it

For those who don’t have time to read this post, I would please request two things:-

1) Please vote for this issue (link given below) and tell others to also do it

2) If you are reading this before 12 PM PST Oct 2, 2015, please take the below survey which will give the feedback directly to the Microsoft Power BI research team (and if you are in the US, you might win a $50 Amazon gift card also). Make sure that you mention “making cross-filtering more intuitive” and “ability to hold selections on more than one chart for cross-filtering” as two points for this question in the survey– “What would make Power BI Desktop a better experience for you?

Please please please do it Smile

How Cross Filtering in Power BI works

Before I start this post, I have to say that I am one of the biggest fans of Power BI, and I have never been as optimistic about a Microsoft BI product as I am right now. (and it’s not just me being a fan boy, the most recent Forrester Wave report shows Microsoft leading the BI pack)

Forrester Wave BI report

The Power BI team is also one of the most responsive teams and you can regularly see the product managers as well as the product team members interacting with the general community on twitter and the Power BI community. But they don’t have an infinite number of resources and time, and hence will be making changes to the product based on priority, and votes are one way we can help the team prioritize the feature requests. The more the votes, the higher the priority and the faster we can get this feature implemented by the product team and this is where I really need all of you to pitch in. Let’s start by taking a look at how cross filtering in Power BI works today:- Let’s say I have 3 charts – bar chart for sales by business lines, bar chart for sales by country and a bubble chart which shows some KPIs by countries.

Power BI dashboard

You can click on any chart and see the rest of the charts refresh for it. For eg, I can click on Nutrition business line and see the other charts refresh for it. However, there are a couple of things I can not do. For eg 1) I want to see the bubble chart for business line – Nutrition and country – Japan. Normally you would expect to click on Nutrition in the first chart, and Japan in the bottom chart to see the cross-filtered bubble chart. However, Power BI currently does not allow us hold selections on multiple charts. The workaround is to add slicers or filters for the needed fields, however it will break the flow when I am trying to find insights from my dashboard.

1 Power BI not able to hold multiple selections

2) I want to see where a particular country is in the bubble chart along with the rest of the countries, so I can assess it’s performance with respect to the other countries. For eg, when I click on Japan in the bottom bar chart, I want Japan to be highlighted in the bubble chart. Right now, you can see from the above image, that when I click on a particular country, only that country appears in the bubble chart because it is filtered. What we need is an option to specify whether we need a chart to be filtered or in this case, highlighted. 3) Cross-filtering during drill downs is the most counter-intuitive feature for me. I had raised this issue in 2013 for Power View and despite getting a lot of votes for the connect issue, the issue is still active. For eg, let’s say the bottom chart shows the sales by Region which can be drilled down into countries. When I drill down into the Greater China region (which only has 3 countries), I expect the top chart to cross filter for Greater China region, which it doesn’t. But if I manually select all the countries, it will cross-filter the top chart appropriately. So in a way, I can take a screenshot of the exact same report showing 2 different data points – which would be very confusing for end users. What we need is for the cross-filtering to work intuitively when we are drilling down.

2 Cross-filtering during Drill down is counter-intuitive

And looks like I am not the only one as I can see 4 comments in the last month on this.

Comment from Microsoft Connect

Comment from Power BI Community

How I feel Cross Filtering should work

I didn’t want to sound pompous by saying this is how it should work; everyone has their own ideas and most of the times, no-one is wrong. But this is why it is important for a BI tool to give options to the end user, so that they can manage the options and choose to use it the way they like. That said, let’s take a look at another popular BI tool – Tableau and see how it handles the above scenarios.

1) Note how the entire report cross-filters as I keep on holding multiple selections.

3 Tableau cross filtering

This experience is very important as I can see what are the top countries for each business line, and then I can also choose a particular country and then see the information for the selected country and business line to analyze in detail.

2) Also note how the country in the bubble chart gets highlighted, when I click on a country in the bar chart. As the number of bubbles increases, it is difficult to see where the selected bubble is unless we have a highlighting feature. The reason why highlighting is important is because it will help us identify patterns by comparing with the rest of the categories.

3) As far as the drill down is concerned, it is not that straight forward in Tableau, but we have options that will help us achieve the end result as I have shown below. You can see that when I click on a particular product category, it drills into the subcategory and all the other charts (the bar chart on the right and the table under it) are also getting filtered appropriately.

5 Tableau drill down

In reality, they are 2 different dashboard sheets, and clicking on the first sheet takes us to the second sheet with the drill down parameters intact (just like with SSRS). But an end user will not be able to get this difference and at the same time achieve the functionality.


It’s amazing how much ground has been covered in Power BI ever since the release, and there have been some really great decisions (like the ability to add custom visualizations – you just have to look at some of the contest entries to see some really great dataviz) as well as features (44 new features in the last monthly release!!!). For all that we know, the team might have already made this change in their next monthly release, or maybe it is still not in the priority list because enough customers do not want this. Either ways, I just wanted to put this out in case you also think the same way, and if yes, make your voice heard in the Survey. Now would be a good time to scroll up to the Action Item part! Smile


As I mentioned before, Power BI versions change rapidly and there are a lot of new features coming in monthly. So it is important to check your version and see if there are any changes. The version at the time of writing this blog is given below-


Posted by SQLJason, 5 comments
My Thoughts on Calculated Tables in Power BI

My Thoughts on Calculated Tables in Power BI

September 24, 2015

Yesterday was a terrific day for all of Microsoft Power BI fans. Microsoft released updates for Power BI Service, Power BI Mobile and Power BI Desktop (with an unbelievable 44 new features) – which basically means no matter whether you are a developer, BI professional or an end user, all of you got something new to play with along with this release. The blogs give a lot of details on what those new features are, so I wouldn’t be going over them. But I wanted to take a moment to pen down a few moments on my thoughts on a new modeling feature within this release – Calculated Tables.

Calculated tables in Power BI

Chris Webb has already posted his thoughts on Calculated Tables in Power BI and I am pretty sure Marco Russo / Alberto Ferrari will post some on the same pretty soon (if not, this is an open request from my side for Marco & Alberto to post something on the topic, pretty please Smile) – [Update 9/28/2015 Read Transition Matrix using Calculated Tables]. As usual, a combination of posts from these folks are going to be the best resource for any topic in the Modeling side, and I learn most of my stuff from them. So you would be thinking – what exactly am I trying to achieve in this post? Well, I would like to add my 2 cents on the same and try to see if the community in general agrees with what I think and if not, to learn from the comments and the interaction this might generate.

I) How to build Calculated Tables in Power BI

Before I start on my thoughts on calculated tables, it might be a good idea to quickly see how we can create calculated tables.

1) First make sure that the version of Power BI is equal to or higher than 2.27.4163.351. (I am making a fair assumption that this feature will be enabled in all higher versions also released in the future). If not, download it from here

Power BI version

2) Now open any of your existing models in Power BI (or get some new data), and after that, click on the Data tab. You should be able to see the New Table icon in the Modeling tab on the top.

New table - calculated table

3) Click on the New Table icon, and then enter any DAX expression in the format that returns a table TableName = DAX Expression that returns a table Once you do that, then you should be able to see the resultant columns in the new table.

Calculated table

II) When is the data in a Calculated Table processed

The official blog says quite a few things on the same-

    • A Calculated Table is like a Calculated Column.
    • It is calculated from other tables and columns already in the model and takes up space in the model just like a calculated column.
    • Calculated Tables are re-calculated when the model is re-processed.

So based on this information, I am going to go a step further and assume that the data in a calculated table is processed during the ProcessRecalc phase of processing. Also, this means that every time any of the source tables changes (like a new calculated column or new data), the data in the calculated table will also change. To prove this, let us try a simple experiment-

1) Make a calculated table called Test which will be the same as the Date table (which currently has just the Year column).

make same calculated table

Note that measures from the source table are not brought along to the calculated table, which is as expected.

2) Now go to the Date table (which is our source table in this case) and then add a new calculated column called TestColumn with 1 as the value.

column replicated in calculated table

Note that when we added a calculated column in the source table, the column was replicated in the calculated Table also with the same name. The only difference is that the source table shows an icon for calculated column. This shows that the ProcessRecalc that happens in the source table when a new calculated column is made, also recalculates the calculated table.

III) My thoughts on Calculated Tables

Based on my understanding so far, there are times when I think I should use calculated tables and times when I should not use calculated tables. So here it goes –

a) When NOT to use calculated tables

If you have a way of replicating the calculated table in some form of ETL or source query (even a SQL View), you should not use a Calculated table. Why? A couple of reasons

  • If done from ETL / source query, the engine will see the result as a regular table, which means parallel processing of the tables can be done (unlike now, where the ProcessData phase of the source tables have to finish first before the calculated tables can be processed). So calculated tables could lead to slower data processing time.
  •  A ProcessRecalc happens every time you do a process full, and adding more calculated tables (as well as calculated columns) unnecessarily will increase the processing time. Also, during development of very large models, you might have to wait for a long time after each calculation is made for the data to appear, since all dependent tables will also have to be recalculated (unless you turn off the automatic calculation mode).
  • This one is more an assumption and further research will be needed to validate this, but I am putting it forward anyways. Just like a calculated column is not that optimized for data storage compared to a regular column, I suspect that a calculated table will also not be optimized for storage compared to a regular table. If this is true, this might affect query performance.

b) When to use calculated tables

There are a lot of scenarios where you would want to use calculated tables and I have listed a few of the scenarios below

  • During debugging complex DAX expressions, it might be easier for us to store the intermediate results in a calculated table and see whether the expressions ate behaving as expected.
  • In a lot of self-service BI scenarios or Prototype scenarios, it is more important to get the results out there faster and hence, it might be difficult or not worth the effort to fiddle with the source queries. Calculated tables can be a quick and easy method to get the desired table structures.
  • A kind of scenario that I see very often during prototyping / PoCs is when there are 2 facts in an excel file which are given for making reports. As seasoned users of Power Pivot / Power BI, we know that we will have to create a proper data model with the dimensions. Now, I might need to create a dimension which gets me the unique values from both the tables. For eg, in the below example, I need the Country dimension to get values from both the tables (USA, Canada, Mexico). It might be easier to write an expression for a calculated table like shown below
    Country = DISTINCT(UNION(DISTINCT(Table1[Country]), DISTINCT(Table2[Country]))) 

2 fact tables with no dimension data

  • There are times (like in some role playing dimensions) where you will need to replicate the columns / calculated columns (or even delete) in another table also, even if the columns are built at a later phase in the project. Calculated tables are a perfect match for that, as you will only need to make the changes in one table, and the changes will flow down to the calculated table during ProcessRecalc phase (remember our previous example where we created a TestColumn in the Date table, and the change was reflected in our calculated table also).
  • Calculated tables can help in speeding up DAX expressions. This is very similar to the technique of using aggregate tables in SQL database to speed up the calculations in SQL.
  • Quick and easy way to create calendar tables (like Chris showed in his blog)

This is still a very early stage as far as Calculated tables are concerned, and I am pretty sure we are going to see some very innovative uses as well as benefits of calculated tables in the days to come. I might also learn that some of my assumptions are wrong, and if I do, I will come back and update this post to the best I can. Meanwhile, feel free to comment on your thoughts / concerns / feedback.

Update – 9/28/2015

Transition Matrix using Calculated Tables – Alberto Ferrari
Use Calculated Table to Figure Out Monthly Subscriber Churn – Jeffrey Wang

Posted by SQLJason, 0 comments
SSRS Line Chart with Data Tables (Excel Style)

SSRS Line Chart with Data Tables (Excel Style)

September 10, 2015

It takes a lot of discipline and dedication to run a blog properly and that is one of the main reasons why I admire bloggers and tech gurus like Chris Webb (who has been putting out high quality blogs for ages in a consistent manner!). Sadly, I am not very disciplined when it comes to writing blogs and it takes a significant external force to make me write nowadays. I had written a blog almost 3 years ago on how to create SSRS charts with data tables like in Excel and from then onwards, I have had a lot of readers ask me on how to do the same with line charts (both through comments as well as emails). I knew it was possible but was too lazy to write a blog on it, until I had 2 readers ask me the same question yesterday in the comments. Finally, I decided to check it out and write about it. The solution is not perfect and is more of a workaround but should be ok for most of you I guess.

SSRS Line Chart with Data Table (Excel Style)

For illustrating the solution, I am using a simple dataset which shows the sales by Product and Month.

Sample dataset

To follow this solution, you must be familiar with the technique I mentioned in the previous article. If you have not read that, please the previous article first and then follow the steps below 1) A lot of readers already found out that if the technique described in the previous article was used, then we will only get points and not actual lines. So, the very first step here is to modify the source query such that for every actual point in the line chart, we get 2 more points which gives the start and end for that point. With this, now we will have a line joining 3 points for what would just have been one point before.

;WITH   Src
AS     (SELECT Product,
WHEN MonthNo = 12 THEN NULL ELSE (lead(Sales, 1, NULL) OVER (PARTITION BY Product ORDER BY MonthNo) + Sales) / 2
END AS LeadSales,
WHEN MonthNo = 1 THEN NULL ELSE (lag(Sales, 1, NULL) OVER (PARTITION BY Product ORDER BY MonthNo) + Sales) / 2
END AS LagSales
        FROM   (<Source Query>) AS O)
SELECT Product,
       ‘1’ AS Type,
       CAST (LagSales AS FLOAT) AS Sales
FROM   Src
SELECT Product,
       ‘2’ AS Type,
       CAST (Sales AS FLOAT) AS Sales
FROM   Src
SELECT Product,
       ‘3’ AS Type,
       CAST (LeadSales AS FLOAT) AS Sales
FROM   Src;

Note that LeadSales column is actually the (Sales for next point + Sales for Current Point) / 2 and LagSales column is actually the (Sales for previous point + Sales for Current Point) / 2. This will help us get a smooth line when we join our different lines. Also, we have to ensure that for the first and last points, NULL values are assigned. The bottom part of the query brings all three columns (Sales, LeadSales, LagSales) into a single column called Sales but each one is assigned a different Type.

Changed Dataset

2) Repeat the steps 2 and 3 in previous article to make the matrix and the two rows above it.

Matrix ssrs

Also add the Type column to the row group, delete the columns only and then filter the Type group for 2 only. The reason is that we only want the actual Sales to be shown in the data table, which is 2. Type 1 and 3 are used for the sole purpose of making the line chart.

1 Type filter

3) Now you should be able to follow the rest of the steps in the previous article with the sole exception that you will be using a line chart and not a bar chart.

2 Line Chart

Make sure that you set the CustomInnerPlotPosition and CustomPosition appropriately like in step 10 in the previous article, so that graph appears continuous. I used the below settings for this line chart.

SSRS CustomPosition

4) Instead of step 11 in the previous article, I chose to make a new column to the left for the vertical axis, and just made sure that the vertical axis for the line charts all have the same scale. Adding column for axis

Note that the series expression for this column is just 0, and there are no category or series group. This ensures that we just get a dummy line for the axis. You can start hiding the orders to ensure that the graph looks continuous.

5) I also added an expression such that the markers and tooltips only show if the type is 2.

SSRS adding expression for markers and Tooltip

6) With all these changes and a bit of formatting, we can get the below result

SSRS data table with line chart

This should be good for most people. However, there is one minor drawback which is that the lines do not join that smoothly. I have just zoomed in one part so that you can see the issue. Maybe, this could be solved by fiddling along with the properties some more, but I feel this is not that big of an issue.

Line chart lines are not smooth

Hopefully this will put to rest some of the questions I keep getting on data tables in SSRS, so that I can go back to my lazy self Smile (just kidding)

Posted by SQLJason, 12 comments