Understanding Power BI Totals: The Math, the Model, and the Misconceptions

The long-running debate around how Power BI calculates totals in tables and matrices has been part of the community conversation for years. Greg Deckler has kept the topic alive through his ongoing “broken totals” posts on social media, often suggesting that Power BI should include a simple toggle to make totals behave more like Excel. His continued campaign prompted a detailed reply from Daniel Otykier in his article No More Measure Totals Shenanigans, and earlier, Diego Scalioni explored how DAX evaluates totals internally in his post Cache me if you can: DAX Totals behind the scenes.

This blog brings all those perspectives together from a scientific and comparative angle. It looks at how totals are calculated in Power BI and compares that behaviour with Tableau, Excel, Paginated Reports, and even T-SQL. The goal is not to take sides, but to clear up the confusion around what is happening under the hood.

Are Power BI Totals Really Broken?

Let’s get one thing clear right at the start, no, Power BI totals are not broken. There is no “it depends” this time. What some interpret as broken behaviour is actually how DAX and the underlying model are designed to work.

This post is not personal, it is purely scientific and technical. While I have great respect for Greg and his significant contributions to the Power BI community, I disagree with the use of the word “BROKEN.” It sounds dramatic but does not reflect the full truth. Totals in Power BI behave exactly as the model and the maths define them to. Want to know why? Keep reading.

Why this matters

When someone with Greg’s influence keeps saying totals are “broken”, it really affects how new users see Power BI. Some even start thinking the tool itself is not reliable, when what they are seeing is actually how different reporting tools do their calculations in different ways.

It helps to know the main calculation styles that these tools use:

  • Cell based: This is what you get in worksheet formulas and classic PivotTables that use Excel ranges. Totals are just simple sums of the shown items, with no model or relationships behind the scene.
  • Model driven: This is how Power BI works and also Excel PivotTables that use the Data Model (Power Pivot) or connect to a tabular dataset. Measures are calculated again for every context, so totals depend on how filters and relationships are set.
  • Query driven: Tools like Paginated Reports work this way. The report runs a query, for example SQL or DAX, gets the dataset, and then sums or averages values in the report design. The author decides how each total should be calculated.
  • Hybrid (query and context driven): Tableau fits in here. It gets the data through a query but also lets you change the level of detail and how totals behave in the visual. So sometimes it acts like a query tool and sometimes more like a model one.

Most of the confusion happens when people compare results from these tools as if they all worked the same way. Once you understand the difference between cell based, model driven, query driven, and hybrid tools, the way Power BI shows its totals starts to make full sense.

The problem that started it

Greg’s long-running example uses a small table with a single column of numbers and a DAX measure like this:

SUMX(SampleData, SampleData[Amount]) - 10

In the total row, the result shows 590, while he expects 580 (two groups of 290 each). Based on that, he argues that Power BI totals are “wrong”.

But DAX is only doing what it is told to do. In this measure, the subtraction of 10 happens after the total amount is calculated, not for each row. If the intention was to take 10 away per row, then the measure should be written like this:

SUMX(SampleData, SampleData[Amount] - 10)

This version gives the expected 580 because the subtraction now happens at the lowest level of detail, which is per row.

This might look like a small detail, but it is exactly where most of the confusion around totals begins. The difference is not about Power BI being wrong; it is about understanding where in the calculation the operation happens.

The math behind it

Before we look at the numbers, let’s first talk about what we are trying to do. We Greg’s small and very simple table that shows some amounts by Category and Colour:

CategoryColourAmount
ARed100
AGreen100
ABlue100
BRed100
BGreen100
BBlue100
Continue reading “Understanding Power BI Totals: The Math, the Model, and the Misconceptions”

Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 2 – Implementation

This blog series complements a YouTube tutorial I published earlier this month, where I quickly covered the scenario and implementation of shared semantic models in Microsoft Fabric. However, I realised this topic demands a more detailed explanation for those who need a deeper understanding of the processes and considerations involved in one of the most common enterprise-grade BI scenarios.

In organisations with strong security and governance requirements, implementing shared semantic models is vital to ensure seamless and secure access to data. These organisations often split roles across various teams responsible for productionising analytics solutions. Typically, they have strict Row-Level Security (RLS) and Object-Level Security (OLS) implemented in their semantic models. The goal is to enable two key groups within the organisation:

  • Report Writers: They must access the semantic models securely. This means having sufficient permissions to create reports while ensuring access is restricted to only the relevant objects and data.
  • End-Users: They need access to trustworthy and relevant information without dealing with underlying complexities. All the heavy lifting should be managed behind the scenes.

The first blog laid the groundwork by covering all the essential core concepts necessary for successfully implementing this scenario. It also provided a clear explanation of the roles involved in the process.

Blog Series Overview

Initially, I planned to cover everything in one post. However, the scope turned out to be too large, so I split it into two parts to ensure clarity and avoid overwhelming readers. Here’s what the series includes:

By the end of this blog, you will apply the understanding from the previous post to a real-world scenario, managing secure access to shared semantic models in Microsoft Fabric, and implement the solution step-by-step.

If you prefer a video format, check out the tutorial on YouTube:

For those who enjoy diving into the details, let’s get started!

Continue reading “Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 2 – Implementation”

Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 1 – Core Concepts

Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models - Part 1 - Core Concepts

Managing and optimising shared semantic models in Microsoft Fabric, with a focus on securing access, is essential in today’s data-driven world. These models are the backbone of an organisation’s analytics, providing consistent and scalable insights across teams. Whether you’re an experienced professional or just starting with Microsoft Fabric, understanding how to manage access to shared semantic models is key to delivering impactful insights.

This blog focuses on the core concepts that are vital for building a strong foundation. These concepts are pivotal for a correct and successful implementation of shared semantic models. Without a solid grasp of these basics, it can be challenging to navigate the complexities of advanced configurations or ensure secure and efficient use of semantic models within Microsoft Fabric.

I originally planned to cover this topic in one blog, but it turned out to be too much for a single post. Splitting it into two parts allows me to explain everything clearly without making it overwhelming. Here’s what the series covers:

By the end of this blog, you’ll understand the basics of managing and optimising secured access to shared semantic models in Microsoft Fabric.

If you prefer a video format, check out the tutorial on YouTube:

For those who enjoy reading the details, keep scrolling!

Requirements

Before diving into the implementation of shared semantic models in Microsoft Fabric, it’s important to understand the prerequisites. This process has specific licensing and role requirements, which are outlined below:

  • At least Power BI Pro license: This is the minimum required license because Workspace functionality is available only with a Pro or higher license. For large semantic models you will required Power BI Premium Per User (PPU) or a Fabric Capacity.
  • Microsoft Fabric Administrator role: Necessary for configuring semantic model discoverability in the Admin Portal.
  • At least Workspace Member role: Required to set permissions on the semantic models.
  • At least Workspace Contributor role: Needed to assign users and security groups to RLS (Row-Level Security) and/or OLS (Object-Level Security) roles.

Ensure that you have the proper licenses and roles assigned before starting the implementation to avoid any disruptions or limitations in managing shared semantic models.

Continue reading “Microsoft Fabric: Unlocking the Secrets to Mastering Shared Semantic Models – Part 1 – Core Concepts”

Separate Your Power BI Versions: How to Change Icons in Windows 11

Separate Your Power BI Versions; How to Change Icons in Windows 11

In a previous blog, we explored the different versions of Power BI Desktop, including the standard Power BI Desktop and Power BI Desktop RS, tailored for Power BI Report Server. In another blog, we discussed the two variations of the standard Power BI Desktop: the Microsoft Store version and the Downloaded version. We also discussed scenarios where having both versions installed side-by-side might be necessary. If you haven’t read those posts yet, I recommend checking them out for helpful insights.

In this blog, we focus on a common challenge when using both versions side-by-side: they share the same icon, making it difficult to quickly tell them apart. This often results in opening the wrong version and disrupting your workflow.

To address this, I’ll guide you through customising the application icons for Power BI Desktop on Windows 11. For those who prefer watching tutorials, here’s a link to the YouTube video:

If you’d rather read through the steps, keep scrolling.

Why Customise Power BI Icons?

As I have already explained here, Power BI Desktop versions serve different purposes. Having both versions installed is recommended for advanced users and organisations with specific use cases. However, their identical icons can cause confusion, particularly when managing multiple projects or workflows.

Continue reading “Separate Your Power BI Versions: How to Change Icons in Windows 11”