Incremental Refresh - Detect Data Changes

Hi powerbiexpert22​,

Detect data changes is an optimisation for the refresh window, not a way to catch updates in history. Without it, every partition in the "refresh rows in the last N" window is reloaded on every refresh. With it, the service first polls the MAX of your last-modified column per partition and only reloads partitions whose max has increased.

Where it pays off: a wide refresh window where only a few periods actually change. For example, a 30-day window because late-arriving orders can be amended up to a month later, but on a typical day only 2 or 3 of those days really get edits.

Policy: archive 5 years, refresh last 30 days, detect changes on ModifiedDate

Without detect changes: 30 daily partitions reloaded every refresh
With detect changes:    30 cheap MAX() polls, then e.g. 3 partitions reloaded

When to skip it:

Window is small (e.g., last 1-3 days)   -> polling saves little
ModifiedDate not reliably maintained     -> missed changes (silent stale data)
Source can't run MAX() efficiently       -> polling cost eats the benefit
Hard deletes at source                   -> deletes don't bump any max

The column must be maintained by the source on every insert and update (trigger, CDC or ETL), and it should be different from the RangeStart/RangeEnd partitioning column. If your change signal is more complex (e.g., a max of two columns), the policy also accepts a custom polling expression via XMLA (pollingExpression in the refreshPolicy), which Tabular Editor can set.

So my overall approach would be:

Wide refresh window + few periods change + reliable ModifiedDate -> enable it
Small window or unreliable ModifiedDate -> leave it off
Complex change logic -> custom pollingExpression via XMLA
Deletes / history fixes -> targeted partition refresh, not detect changes

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.