Visuals show incorrect data until I re-publish the dataset

1. Hi ChristianW
   
   when Power BI caches the visual results for the current week, and then the week rolls over (or a refresh runs at a certain time), the cache still holds the previous week's aggregated numbers. The summarised export shows the same wrong data because it reads from that same cache — while the underlying data export bypasses the cache entirely and reads the raw model, which is correct.
   
   
   try these 
   
   Go to the dataset settings in Power BI Service → find Query Caching → turn it Off. This is the most direct fix if you're on Premium capacity
2.  
3. 
   Check how the current week is defined in your model. If you're using TODAY(), NOW(), or a relative date filter, these run in UTC  so depending on your timezone, the "current week" could be resolving to the wrong week at the time of refresh.
   
   

worth checking this too

In your workspace, go to the dataset settings and check if Query scale-out is enabled , if so, try disabling it and see if the problem stops occurring.

Hi ChristianW ,

To help isolate the root cause, I would recommend checking the following:

Auto Date/Time or hidden date tables
If you're using the week as a string (e.g., 2026cw13), verify there isn’t any implicit date table or relationship causing unintended grouping behavior.

Column data types & sorting behavior
Ensure the week column is consistently treated as text (or properly modeled with a numeric sort column).
Mis-sorting can sometimes lead to aggregation overlap between adjacent periods.

Duplicate keys / granularity issues
Since underlying data exports are correct, validate whether there are duplicate combinations at the model level (e.g., Type + Week) that could be getting re-aggregated incorrectly in visuals.

Measure logic vs implicit aggregation
If visuals rely on implicit SUM instead of explicit measures, try recreating them using a DAX measure to rule out aggregation inconsistencies.

Service-side caching artifacts
Even with query caching disabled, there can be residual cache behavior.
As a test, try:
Clearing dataset cache via XMLA (if available)
Renaming the dataset (forces a new artifact ID without deletion)
Publishing to a new workspace to compare behavior

CSV ingestion consistency
Double-check if the latest week’s CSV is ever overwritten or appended in a way that could temporarily duplicate prior week values during refresh windows.

Given that deleting and re-publishing fully resolves it (temporarily), this strongly suggests state inconsistency in the dataset artifact rather than a modeling issue.

Hope this helps.
Thank you

Hi ChristianW ,

Thanks again for sharing the detailed model setup, this really helps narrow things down. Based on everything you’ve validated so far, this no longer appears to be a typical modeling, sorting, or duplication issue.

Instead, the behavior strongly suggests a refresh-time inconsistency affecting only the latest data slice. This is reinforced by the fact that older weeks remain stable, while only the current week shows incorrect aggregation. The most likely causes in this scenario are either file overwrite timing during ingestion or an internal processing/cache inconsistency for newly ingested data.

To help isolate and resolve the issue, I would recommend validating the following:

First, try forcing a true full rebuild of the dataset. Even without incremental refresh enabled, the service can apply internal optimizations. Disable the scheduled refresh, delete the dataset, republish it, and perform an initial refresh. Then trigger a second refresh and observe whether the issue reappears.

Next, pay close attention to file replacement timing, as this is a common root cause in similar scenarios. Since your files are written daily to S3, ensure that the current week’s file is not being overwritten. Replacing a file with the same name can sometimes lead to inconsistent reads during refresh. A more reliable approach is to use immutable file naming, such as including a timestamp or version in the file name, rather than overwriting existing files.

It’s also worth validating for any mixed granularity collisions in the fact table. Since your model contains both weekly and monthly aggregates, ensure that for the current week there is no unintended overlap for example, the same date_id appearing across different granularities, or filters not strictly enforcing the intended granularity context.

Additionally, review the relationship configuration in your model. With the Granularity (1:n) and Timespan (n:1 → 1:n) relationships, confirm that all relationships are set to single direction filtering and that there is no ambiguity or bidirectional filtering affecting filter propagation.

Finally, since deleting and republishing temporarily resolves the issue, it’s worth testing whether this is related to hidden model metadata. To rule this out, create a new PBIX from scratch, re import the queries, rebuild the model, and publish it as a completely new dataset instead of reusing the existing one.

These steps should help determine whether the issue is rooted in ingestion timing, model design edge cases, or a service side inconsistency.

Thank you.

Hi ChristianW ,

We’d like to follow up regarding the recent concern. Kindly confirm whether the issue has been resolved, or if further assistance is still required. We are available to support you and are committed to helping you reach a resolution.

Thank you.

Hi ChristianW ,

We’d like to follow up regarding the recent concern. Kindly confirm whether the issue has been resolved, or if further assistance is still required. We are available to support you and are committed to helping you reach a resolution.

Thank you.