Incremental refresh - deletion

Hi powerbiexpert22​,

Yes, your understanding is correct, and I need to correct what I wrote in your earlier thread: "Detect data changes" only applies to partitions inside the incremental (refresh) window. Within that window it skips partitions whose max(ModifiedDate) has not changed; partitions in the historical/archive range are never re-read by a policy refresh, even if their rows changed. Sorry for the confusion.

So changes or soft-deletes in 1 Aug to 24 Oct need an explicit refresh of those partitions. Options, from simplest to most precise:

1. Widen the refresh window temporarily (e.g. refresh last 3 months),
   run one refresh, then set it back. Simple, but reprocesses everything in it.

2. Refresh only the affected historical partitions via the enhanced refresh
   API (or SSMS / Tabular Editor over XMLA), without touching the policy.

POST https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}/refreshes
{
  "type": "full",
  "applyRefreshPolicy": false,
  "objects": [
    { "table": "Sales", "partition": "2026Q309" },
    { "table": "Sales", "partition": "2026Q310" }
  ]
}

Partition names follow the policy granularity (you can list them with INFO.PARTITIONS, see your other thread on checking partitions). A practical pattern is a small scheduled job that finds which months had changes in the source (max ModifiedDate per month since the last run) and refreshes just those partitions with the call above.

So my overall approach would be:

Detect data changes = only the incremental window (your reading is right)
-> Historical changes: targeted partition refresh via API/XMLA
-> Automate: find changed months in source, refresh those partitions
-> Or temporarily widen the refresh window for one-off corrections

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

Hi BeaBF​ ,

I am using fabric capacity, which is the good option you would suggest

1. SSMS, Tabular Editor or TMDL .
2. Sue the Rest API

I am looking for something which I can automate , if you think second option is good then could you please share approach for option2

Hi powerbiexpert22​ ,

Yes, your understanding is basically correct, with one clarification.

How "Detect data changes" works

• On each refresh, the service checks the MAX of your ModifiedDate column for each partition in the incremental range only. In your case that's 25–27 Oct 2026.
• If that value hasn't changed since the last refresh, the partition is skipped. If it has changed, the partition is reprocessed.
• Partitions in the archive range (1 Aug – 24 Oct 2026) are never checked and never reprocessed by a scheduled refresh. The policy treats them as stable. "Detect data changes" makes the incremental range cheaper to refresh. It doesn't extend coverage into history.

One clarification: "can never refresh" A scheduled refresh won't touch those partitions, but you can refresh them yourself without reloading the whole table:

1. Refresh specific partitions over the XMLA endpoint (SSMS, Tabular Editor or a TMSL script). Target only the affected month or day partition. Set applyRefreshPolicy: false if you refresh at table level and want the policy logic skipped.
2. Use the enhanced refresh REST API with an objects list naming the table and partition. You can run it from a pipeline, Power Automate or a notebook using semantic link.
3. Widen the incremental range, for example from 3 days to however late your corrections usually arrive. Combined with "Detect data changes", only the partitions that actually changed get reprocessed, so this is often the simplest fix.
   
   

Options 1 and 2 need Premium, PPU or Fabric capacity.

One thing to watch: partition your table on a stable business date, such as an order or transaction date, not on ModifiedDate. If you partition on ModifiedDate, an edited old row lands in today's partition while its old copy stays in the historical partition, and you get duplicates.

Deletes: as discussed in your other thread, deleted rows in historical partitions stay in the model until that partition is refreshed. So either use soft deletes (IsDeleted plus an updated ModifiedDate) within the incremental range, or run a periodic targeted refresh of the historical partitions, for example weekly or monthly via XMLA or REST.

Reference: Configure incremental refresh for Power BI semantic models - Power BI | Microsoft Learn

Let me know. BBF