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.

If you are into podcasts and prefer the audio version of this blog, I got you covered. Here an AI generated podcast for this blog. 👇

Power BI’s Broken Totals – Myth Debunked

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: Revealing Cost-Saving Results from Automating Pause & Resume Fabric Capacity

Microsoft Fabric: Revealing Cost-Saving Results from Automating Pause & Resume Fabric Capacity

If you work in data and analytics, particularly within the Microsoft Data Platform, you have likely heard of Microsoft Fabric and its many capabilities. However, one of the biggest challenges organisations face is managing costs effectively.

In previous blogs and videos, I have covered how to optimise Microsoft Fabric capacity costs by automating the pause and resume process using Logic Apps. This approach ensures that your Fabric capacity runs only when needed, reducing unnecessary expenses. But how much can this method actually save? In this post, I share the real cost-saving results after applying this automation over the past few months.

Why Automate Pause & Resume?

Microsoft Fabric is a powerful platform, but maintaining capacity during off-peak hours can be costly. If your workloads are not running 24/7, you might be paying for unused capacity. By automating the pause and resume process, you can ensure that your environment is active only when required, leading to substantial savings.

When Should Organisations Consider Automation?

Not every organisation requires automated capacity management, but here are some scenarios where it makes sense:

  • Non-Continuous Workloads: If your organisation runs batch processing, reporting, or analytics workloads that do not need 24/7 uptime, automation can help cut costs.
  • Business Hours Usage: If your team primarily operates during specific hours, pausing capacity during off-hours prevents unnecessary spending.
  • Seasonal or Project-Based Needs: Companies with fluctuating workloads based on seasons or projects can optimise expenses by automating capacity scaling.
Continue reading “Microsoft Fabric: Revealing Cost-Saving Results from Automating Pause & Resume Fabric Capacity”

Power BI Desktop Versions Demystified: Part 1, Power BI Desktop and Power BI Desktop RS

If you are a Power BI power user, you may have wondered: how many versions of Power BI Desktop are there? The quick answer is: it depends!

Depending on your organisation’s preferences, data governance requirements, and the platforms you intend to use for report deployment you may use either Power BI Desktop, the “standard version”, or Power BI Desktop RS (Report Server). Power BI Desktop has variations tailored to meet specific needs, such as cloud-based analytics or on-premises reporting. While many users might only encounter the standard version, there’s another important variant for specialised scenarios.

Power BI Desktop comes in two primary versions:

  1. Power BI Desktop:
    This is the standard version most users rely on. It’s the go-to tool for transforming data, creating semantic models, and building interactive reports. This version is designed to seamlessly integrate with the Power BI Service hosted on Microsoft Fabric, enabling cloud-based sharing, collaboration, and advanced features like Direct LakeAI-driven insights, and more. Regular updates ensure that this version includes the latest features and innovations, such as new Power Query and DAX functions, enhanced visuals, and cutting-edge integrations.
  1. Power BI Desktop RS (Report Server):
    This is a specialised version of Power BI Desktop designed to work exclusively with Power BI Report Server, a locally hosted reporting platform. It is tailored for organisations that prefer to keep their data and reports on-premises due to regulatory, security, or strategic reasons, avoiding reliance on cloud services like the Power BI Service on Microsoft Fabric. Although the two versions look nearly identical in functionality, they serve distinct purposes. Power BI Desktop RS is specifically aligned with the capabilities of Power BI Report Server, supporting features available up to the latest release cycle of the server. For instance, Power BI Desktop RS updates are less frequent; typically released every few months, in line with Power BI Report Server’s update schedule; making it slightly behind the standard version in terms of cutting-edge features. However, it ensures stability and compatibility for on-premises deployments.
Continue reading “Power BI Desktop Versions Demystified: Part 1, Power BI Desktop and Power BI Desktop RS”

Microsoft Fabric: Troubleshooting Query Parameters in Published Semantic Models

Microsoft Fabric: Troubleshooting Query Parameters in Published Semantic Models

Power Query is a powerful tool within the Microsoft Fabric environment, enabling users to manage data sources and transform data efficiently. However, a common issue you may face is that after publishing the Semantic Model, the Power Query parameters either do not appear or are greyed out, making them non-editable. In this post and its accompanying YouTube video, I’ll walk you through the steps to diagnose and fix these problems, ensuring that your parameters work as expected in your published semantic models.

Why Do Power Query Parameters Become Unavailable?

There are a few reasons why your Power Query parameters might not appear or be editable after you’ve published your report to Microsoft Fabric. These issues generally relate to either the way the parameters are set up within Power Query in Power BI Desktop or how they interact with the data sources.

Common Cause and Fix

1. Parameter Data Type in Power Query

One of the most common reasons your parameters might be greyed out or non-editable is due to the parameters’ data types defined in Power Query within Power BI Desktop. If your parameters are of type any, then they won’t show up, or they are read-only (greyed out). The fixation is easy:

Continue reading “Microsoft Fabric: Troubleshooting Query Parameters in Published Semantic Models”