Here’s some of the things I hate about Power BI, or as a client once put it, here are my list of grievances:
1. Column Chart Data Labels Not Obeying the Outside End Position Format
Create a simple column chart. Set the Minimum Range of the Y-Axis to 0, add data labels and set the position to Outside End. It’s a basic formatting setting and shouldn’t be too difficult for the UI to get right straight out of the box.
But as you can see above, for October, Outside End doesn’t actually mean outside end. There’s 2 workarounds for this:
- Set the Minimum range on the Y-Axis to Auto, but deleting whatever value has been set.
- Create a calculated measure that calculates the maximum value + 25% to show as the maximum range on the Y-Axis. This leaves space for the label to correctly display on the outside end:
COGS Max Value +25% Max Range =
VAR MaxValue = MAXX(ALLSELECTED('Financials'[Date].[Year],'Financials'[Date].[Month] ), [Sum of COGS])
RETURN MaxValue * 1.25
// NOTE: For this to work correctly you MUST use a calculated measure. Calculating the measure inline, I.e. SUM(‘Financials'[COGS]) in place of [Sum of COGS] won’t work!
2. Dual Axis Charts – Sharing an Axis
Dual axis charts are really useful to performing comparative analysis. However, when performing comparative analysis, it’s best practice to use the same scale for both measures. This allows the report consumer to be able to get a reading at a quick glance.
Good luck trying to make sense of the chart above at a quick glance! 8.1M for sales in July is below the mark for 7.2M COGS. It almost looks like the company is running at a loss. Now, it is possible to manually go in and set the minimum / maximum range of the Y-Axis and Secondary Y-Axis to be the same, but this does take a few steps and is not exactly intuitive. Why can we just have a checkbox for Shared Y-Axis? We have the option to Align zeros, so why not Align Axes?
Even with this poorly formatted visual, having the Y-Axes aligned makes it simple to perform a comparison at a glance.
To do the Axes alignment above, I’ve manually set both to have a Maximum value of 13M and aligned Zero’s. To do this properly you’d need to create a measure that takes the MAX of both the line and column values and use this as the Maximum. It’s extra overhead that is time consuming for something that should work out-of-the-box.
3. “Working on it” – Waiting For Everything!
Click New Column or New Measure, and wait for 30+ seconds while Power BI performs whatever checks it needs. It’s almost instant if working with a small data model, but it gets considerably worse the larger and more complex the data model is. Why does it have to do these checks before any change has been made?
It then takes another 30+ seconds to commit the change. This I can understand as it works through to ensure the integrity of the model and make any updates to existing visuals. The 30 seconds at the start kills the workflow and reduces productivity. It’s even more painful if you accidentally click Add Column instead of Add Measure and need to wait again. Why not do the initial checks in the background while the Column or Measure is being built?
Changing the field name of a visual can also have these 30+ second delays. Why? There’s nothing else in the report that needs to be updated.
Unfortunately, I don’t have a workaround for this other than a healthy dose of patience.
4. More waiting!
Again, with large data models, it takes 30+ seconds to save a new measure – even if the measure has a syntax error that the DAX parser recognises before committing the change. If the DAX parser knows there is a syntax error (for example if you accidentally hit Enter while entering a DAX statement), why automatically try to commit the measure? A much smarter way to handle this would be to prompt the user if they want to commit the change with the known error – the parser has already recognised there’s an issue.
All of this waiting when working with large data models is a massive productivity killer. It’s not just the time waiting that slows the developer. It’s also having to refocus and recall where you what you were trying to accomplish after the pause. It leads the developer to lose their train of thought!
There’s more!
This is just the tip of the iceberg! I’ll be adding to this list as time permits.
I wish the Power BI team would spend more time on getting some of these fundamentals right, instead of spending their time on some of the edge-case functionality they release each month.
