Partitions Name - Incremental Refresh

Hi powerbiexpert22​,

This is expected behavior, and the extra partition is a side effect of how the refresh window is anchored. I am describing it from the documented design rather than from your model, so please verify with the check below.

What is happening. With month granularity, each partition covers one calendar month, but the incremental window is a rolling range counted back from the refresh date, not from the first day of the month. A 6-month window that starts a bit into April still has to touch the April partition, so you can see seven month partitions (April to October) even though the policy says 6 months.

To see exactly what the service created, connect to the XMLA endpoint (SSMS or Tabular Editor) and list the table partitions. Partition names follow the period they cover, and RefreshedTime shows which ones were refreshed last:

-- DAX Studio / SSMS (XMLA connection to the semantic model)
SELECT [TableID], [Name], [RefreshedTime]
FROM $SYSTEM.TMSCHEMA_PARTITIONS

A few practical points:

Partition names  -> generated by the service from the period (e.g. a 2026-04 style key); not user-defined
Partition count   -> archive periods + refresh periods + the partial boundary period
Boundary month    -> partially covered, so it is part of the refresh set
Historical months -> only refreshed if they fall inside the refresh window

If the extra month matters for refresh time, shorten the refresh period by one unit or switch to a daily granularity for the refresh part so the boundary partition is smaller.

So my overall approach would be:

Confirm -> list partitions over XMLA, check refresh timestamps
Decide  -> accept the boundary partition, or tune granularity/refresh period
Monitor -> watch refresh duration after the change

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

Hipowerbiexpert22​,

This is normal behaviour with Incremental Refresh.

The 6 months setting defines the rolling refresh window, but it does not always mean Power BI will create exactly 6 physical partitions.

If the refresh window starts part-way through a month, Power BI may keep an extra monthly partition to cover that partial period.

So seeing 7 partitions for a 6-month refresh policy can be expected. Power BI manages those partitions automatically, so normally no change is required.

Best Regards,

Maruthi

Hello powerbiexpert22​,

From what I've seen, this is expected behaviour with Power BI incremental refresh.

Having seven monthly partitions doesn't necessarily mean seven months are being refreshed. The April partition may represent the historical boundary, while May through October fall within your six-month refresh window.

To confirm, inspect the partition date ranges and refresh timestamps through the XMLA endpoint. Microsoft's incremental refresh partition documentation explains the naming and partition management strategy in more detail.

Hope this helps.