What it is
Enhanced Refresh is a Power BI REST API capability available for Premium Per User (PPU), Premium, and Fabric workspaces. It extends the standard refresh API by allowing per-object (per-table) refresh control and returning detailed timing for each object processed.
With Enhanced Refresh, each table in a semantic model can be refreshed independently, and the API response includes start time, end time, and status for each table. This enables granular performance monitoring that is not possible with standard refreshes.
The standard refresh API treats the entire dataset as one unit: it either succeeds or fails. Enhanced Refresh reveals what happens inside the refresh — which tables are slow, which tables failed, and how much time was spent on model processing versus data loading.
Why it matters for Power BI teams
- Per-table timing reveals bottlenecks that are invisible with standard refresh monitoring.
- Selective refresh lets teams refresh only the tables that changed, reducing refresh duration and capacity consumption.
- Model build time (the processing phase after data loading) is measured separately, helping diagnose post-load performance issues.
- Parallel processing visibility shows which tables refresh concurrently and which block each other.
- Enhanced Refresh is the foundation for advanced monitoring — without it, refresh timing is a single aggregate number.
Why Power BI doesn't catch it well
The Enhanced Refresh API is available only via the REST API — there is no portal UI for viewing per-table timing. Admins must build their own tooling to capture and visualize this data.
Power BI does not persist per-table timing data. The information is available only at the time of the API response. If it is not captured immediately, it is lost.
There is no historical comparison or trend analysis for per-table timing in Power BI. Each refresh's per-table data must be stored and analyzed externally.
How teams detect it today
- Building custom applications that call the Enhanced Refresh API and store per-table timing in a database.
- Using PowerShell or Python scripts to poll refresh status and parse per-object results.
- Running XMLA traces to capture per-table events — technically complex and resource-intensive.
- Ignoring per-table timing entirely and diagnosing slow refreshes by trial and error.
How SummitView helps
- SummitView's agent automatically uses the Enhanced Refresh API for PPU and Fabric workspaces, capturing per-table timing without any manual setup.
- A processing timeline visualization shows which tables refreshed in parallel and which ran sequentially.
- Each table's duration is compared against its historical average, with faster/slower badges for quick identification.
- Model build time is calculated and displayed separately from table refresh time.
- Row counts per table are captured alongside timing, connecting performance data with data quality signals.