Forum Discussion
Post ProdigyIncremental Refresh completes successfully but latest source data is not reflected in reports
I am observing an unexpected behavior with Incremental Refresh and would like to understand if this is expected.
My current configuration:
Incremental Refresh partition column: UPDATE_DATETIME
Refresh rows: Last 7 Days
Detect Data Changes: Disabled
Data source supports query folding.
My understanding is that with Detect Data Changes disabled, Power BI should fully refresh all partitions within the 7-day refresh window during every refresh.
However, I am seeing the following behavior:
Yesterday, after a manual refresh, the report data matched the database exactly.
Today, the source database contains newer/updated data.
I manually triggered the dataset refresh multiple times, and all refreshes completed successfully.
Despite this, the report is still showing old values and is not reflecting the latest database updates.
To investigate, I queried the source and found that records for older CALL_DATE values continue to receive newer UPDATE_DATETIME values.
Example:
CALL_DATE MAX(UPDATE_DATETIME)
| 2026-06-15 | 2026-06-18 10:05 |
| 2026-06-16 | 2026-06-18 10:05 |
| 2026-06-17 | 2026-06-18 17:00 |
| 2026-06-18 | 2026-06-19 08:00 |
| 2026-06-19 | 2026-06-19 08:30 |
Since Detect Data Changes is disabled, I expected all partitions within the last 7 days to be refreshed regardless of data changes.
My questions are:
With Detect Data Changes disabled, should Power BI always reload all rows in the refresh window during every refresh?
Under what circumstances can a successful incremental refresh complete but still not reflect the latest source data?
Has anyone observed similar behavior when using a mutable column such as UPDATE_DATETIME as the partition column?
Any guidance would be greatly appreciated.
Thanks.
Your partition column is the problem. You're partitioning on UPDATE_DATETIME but filtering rows that belong to old CALL_DATE values.
Fix: partition on the stable business date (CALL_DATE), not the mutable UPDATE_DATETIME. Use UPDATE_DATETIME only for Detect Data Changes.
yes, it reloads all rows in the window, but "the window" is defined by UPDATE_DATETIME, so rows whose UPDATE_DATETIME falls outside the last 7 days never reload even though their CALL_DATE looks recent.
4 Replies
- rajendraongole1
Super User
Hi manoj_0911 - If business rows can be updated up to N days after their CALL_DATE, your incremental refresh window must be larger than N, or you need a second mechanism to catch stragglers. Set "Refresh rows from the last" to cover the realistic update lag (e.g., 30 or 60 days), and optionally still keep a smaller "Incrementally refresh in real-time" / fewer-days window for performance - but the refresh window must be ≥ max update lag, not just ≥ reporting window.
Hope this helps
- manoj_0911
Thank you for your response.
In my case, the Incremental Refresh partition column is UPDATE_DATETIME, not CALL_DATE.
Whenever a record is updated, the UPDATE_DATETIME value is also updated.
For example, if a record with CALL_DATE = 2026-06-15 is modified on 2026-06-19, the UPDATE_DATETIME for that row becomes 2026-06-19, which should place the row within the current 7-day refresh window.
Since Detect Data Changes is disabled, my understanding is that Power BI should fully refresh all partitions within the last 7 days during every refresh.
Given this setup, I am trying to understand under what circumstances a successful refresh could still fail to reflect the latest source data.
Any additional insights would be greatly appreciated.
Thanks.
sample for your review
- Kedar_Pande
Your partition column is the problem. You're partitioning on UPDATE_DATETIME but filtering rows that belong to old CALL_DATE values.
Fix: partition on the stable business date (CALL_DATE), not the mutable UPDATE_DATETIME. Use UPDATE_DATETIME only for Detect Data Changes.
yes, it reloads all rows in the window, but "the window" is defined by UPDATE_DATETIME, so rows whose UPDATE_DATETIME falls outside the last 7 days never reload even though their CALL_DATE looks recent. 
v-pnaroju-msftCommunity Support
Thankyou, rajendraongole1 and Kedar_Pande for your responses.
Hi manoj_0911,
We appreciate your inquiry through the Microsoft Fabric Community Forum.
We would like to inquire whether have you got the chance to check the solution provided by Kedar_Pande to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
Thank you.
