Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Request now

Reply
John_Doe3
Helper II
Helper II

Totals/sum/whatever instead of actual values?

Greetings,

 

Question from a novice user:

 

Why does Power BI always use totals, sums etc? If I grab the same data in excel and say: "Build me a d^%$ chart, it will work straightaway and there are absolutely no issues. It sees a table, it plots the graph. But Power BI insists on raising my blood pressure instead. Is there an actual reason why Power BI does this? I'm now on page 7 of my search, and I still don't know how to fix this. I put everything to "dont summarize", but still it throws a fit and insists on showing cumulative totals where there should be simple individual values. 

 

Again, I can make this graph in Excel in under 5 seconds. In Power BI, we're now entering hour #2, and it still won't play ball.

1 ACCEPTED SOLUTION
v-karpurapud
Community Support
Community Support

Hi @John_Doe3

 

Thank you for reaching out to the Microsoft Fabric Community Forum. Also, thank you @OktayPamuk80 for responding on this topic.

 

Power BI is built on a semantic data model, designed for analyzing large datasets unlike Excel, which directly plots individual rows. As a result, numeric fields are automatically aggregated (e.g., sum, count) when added to visuals.

 

Even if a field is set to “Don’t summarize,” Power BI may still aggregate it based on how the visual is structured. Specifically, if the Axis field contains repeating values (such as Date or Category), Power BI will group by that field and aggregate the corresponding numeric values. It's also important to note that changing a field’s default summarization only applies to newly created visuals, not existing ones.

 

To avoid unwanted aggregation, use a Table visual to verify raw data, ensure your Axis field uniquely identifies each row (like a timestamp or ID), and if needed, use a DAX measure like

ShowRawValue = SELECTEDVALUE('Table'[Column_Name]) to force display of individual values only when exactly one exists in the current context.

This approach gives  more control over how data is visualized and ensures the results match your expectations.

 

If this response resolves your query, kindly mark it as Accepted Solution to help other community members. A Kudos is also appreciated if you found the response helpful.

 

 

Thank You!

 

View solution in original post

7 REPLIES 7
v-karpurapud
Community Support
Community Support

Hi @John_Doe3 

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. If my response has addressed your query, please accept it as a solution and give a 'Kudos' so other members can easily find it.

Thank you.

 

Hi v-karpurapud,

 

Apologies, it's crazy busy here at my place of employement, I forgot to mark it as solution to the issue. The provided solution worked for me. 

 

I really appreciate the help provided!

 

v-karpurapud
Community Support
Community Support

Hi @John_Doe3 

May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.

Thank you.

v-karpurapud
Community Support
Community Support

Hi @John_Doe3

 

Thank you for reaching out to the Microsoft Fabric Community Forum. Also, thank you @OktayPamuk80 for responding on this topic.

 

Power BI is built on a semantic data model, designed for analyzing large datasets unlike Excel, which directly plots individual rows. As a result, numeric fields are automatically aggregated (e.g., sum, count) when added to visuals.

 

Even if a field is set to “Don’t summarize,” Power BI may still aggregate it based on how the visual is structured. Specifically, if the Axis field contains repeating values (such as Date or Category), Power BI will group by that field and aggregate the corresponding numeric values. It's also important to note that changing a field’s default summarization only applies to newly created visuals, not existing ones.

 

To avoid unwanted aggregation, use a Table visual to verify raw data, ensure your Axis field uniquely identifies each row (like a timestamp or ID), and if needed, use a DAX measure like

ShowRawValue = SELECTEDVALUE('Table'[Column_Name]) to force display of individual values only when exactly one exists in the current context.

This approach gives  more control over how data is visualized and ensures the results match your expectations.

 

If this response resolves your query, kindly mark it as Accepted Solution to help other community members. A Kudos is also appreciated if you found the response helpful.

 

 

Thank You!

 

This is good to know, yet at best this a bug, not a feature.
(MS justifiying a bug by saying it's baked in doesn't mean it's not a bug.)

It violates user intent, silently fails, and is inconsistent in its behaviour (EG "_may_ still aggregate")

And silent as from the conditions that are apparent to a user.
At the very least, it should not be incumbant on the user to reverse engineer where the failure is.
If an ingestion assumption overides user code, it should be announced by Power BI to the user.

I currently have values by row in the Transform screen and those end up as an aggregate in Power BI.

I have yet to find a clear, consistent _workaround_ to accomodate this gap in Power BI's data ingestion logic from values correctly determined in the Transform screen.

Figured out an overly cute workaround.
I used FORMAT to force row level calculations in DAX:
CalcdCol = ROUND( VALUE(Table[OriginalColumn] ) / 60, 0)

I do not know if this works in a general context.
I have only verified it in this specific case (and what that actual case is, is opaque to me)

But the workaround seems to be:
Wrap your calculations in an unnecessary function in order to force Power BI to respect the user intent and not aggregate.

This needs to be done in DAX.
Since, even if it is a row level calculation with M Code in Transform with unnecessary steps added, Power BI will still have the final decision if it's to be aggregated.

The clear user intent in M Code calc'd cols are not considered by Power BI's ingestion.
The row by row values are only kept if that logic happens to align with what Power BI desires.

Which adds to refresh overhead as it needs to be a calculated column written in DAX in Power BI instead of in M Code in the Transform/Power Query stage.

OktayPamuk80
Responsive Resident
Responsive Resident

Hi John,

First, changing an field's default summarization, doesn't change the already existing charts' summarizations. It will more change the future ones. Therefore, it is advisable to set the metadata "format, datatype, default Summarization, folder" and validate the data before starting building the visuals.

 

Does this relate to you issue?

Regards,
Oktay

Helpful resources

Announcements
November Power BI Update Carousel

Power BI Monthly Update - November 2025

Check out the November 2025 Power BI update to learn about new features.

Fabric Data Days Carousel

Fabric Data Days

Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.

Top Solution Authors
Top Kudoed Authors