Semantic Model Incremental Schedule Refresh

Hi Saum02​,

Yes, this can happen, but I would not expect scheduled refresh to be inherently slower simply because it is scheduled.

Microsoft documents both on-demand semantic model refresh and scheduled semantic model refresh as background operations, and both should apply the same incremental refresh policy.

I would first check whether you are comparing the actual refresh duration in Refresh history or the elapsed time from the scheduled time.

Microsoft notes in the scheduled refresh documentation that a scheduled refresh is targeted to start within 15 minutes of the configured time, but it can be delayed by up to an hour if the service cannot allocate resources. A manual refresh started at a quieter time would not necessarily see the same delay.

Since your source is Business Central through OData, I would also check the source side rather than only Fabric capacity.

Business Central has documented OData concurrency and rate limits, and requests can be queued or throttled when the service is busy. Microsoft's Business Central web-service performance guidance specifically calls out 429, 503 and 504 responses for throttling, temporary unavailability and long-running requests.

If your scheduled refresh runs at the same time as other BC integrations, API jobs or reporting workloads, the OData source could therefore be slower even when the Fabric capacity itself is not heavily loaded.

I would also verify query folding for the incremental-refresh table.

Microsoft's incremental refresh troubleshooting guidance explains that Power BI creates a query for each partition. The RangeStart and RangeEnd filters should ideally be pushed back to the source. If they are not folding correctly, significantly more data can be retrieved than expected.

My troubleshooting order would be:

• compare actual Refresh history durations rather than scheduled start times
• check the Fabric Capacity Metrics app for contention/throttling at both timestamps
• check whether the RangeStart/RangeEnd filters are folding to Business Central
• check Business Central telemetry/logs for OData throttling or slow requests during the scheduled window
• compare whether the same number of incremental partitions were processed in both runs

If the manual and scheduled runs process the same partitions with the same folded source queries, but the scheduled run is still consistently slower, the timing of capacity usage and Business Central OData activity would be the next places I would investigate.

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