Incremental Refresh doubts

Hello manoj_0911 

IR filters do NOT propagate through relationships. Your fact tables are doing full scans every refresh.

Incremental Refresh works at Power Query level only. Relationships exist in the semantic model the data source has no knowledge of them during refresh.

Add RangeStart/RangeEn` directly in the Power Query of each fact table using TXN_DATE

Table.SelectRows(LOS_REPORT_V, each
[TXN_DATE] >= RangeStart and [TXN_DATE] < RangeEnd)

Do the same for IVR_SUBHOUR_V. Then configure Incremental Refresh on both fact tables using TXN_DATE

In your model, you set up Incremental Refresh on the Date table using TXN_DATE, and it correctly filtered that table during refresh. You could see SQL queries being partitioned on the date dimension, which looked like it was working as expected.

But when you traced the fact tables like LOS_REPORT_V and IVR_SUBHOUR_V, they were still being scanned without any date filters. That’s because Power BI does not push Incremental Refresh filters through relationships during refresh. Relationships only help during report query time, not during data loading.

So even though the Date table was filtered, the fact tables were still processed in full, which caused high CU usage, slow refreshes, and query conflicts.

When you tried moving Incremental Refresh directly to the fact tables using UPDATE_DATETIME, the behavior became unstable, likely due to folding issues or complex transformations breaking the partition logic. That’s why it felt unreliable.

The key realization is that Incremental Refresh must live on the same table that physically holds the filter column. It does not travel across relationships. If the fact table is large, it must be partitioned directly using its own date column, with proper query folding and indexing.

In the end, the Date dimension should stay simple, while each large fact table carries its own Incremental Refresh logic. This shift is what turns a slow, expensive refresh process into a predictable and scalable one.