Prepare Power BI refresh automation by identifying the semantic model, its connection route and the person responsible for a failed or questionable result. Check the trigger’s actual monitoring behaviour before relying on email alerts. Keep refresh completion, report verification and approval of any downstream business action as separate decisions with their own evidence.
Begin with the decision the report supports. Record the data source, semantic model, report audience and intended refresh arrangement. Ask the report owner what they need to know before acting on a new result. A refresh status is one part of that evidence, alongside whether the expected source period and calculation are represented.
Which refresh arrangement is being automated?
Microsoft’s scheduled-refresh guide explains the configuration. Scheduled-refresh settings define the frequency and time slots for a semantic model. Some data sources need a gateway for refresh, while others do not. Identify the actual source connection before choosing the operational checks.
Personal-gateway refresh requires credentials for the back-end data source. For the on-premises gateway, the gateway administrator defines the data-source credentials. Keep that responsibility clear in the handover so a report owner knows which administrator can investigate the relevant connection rather than changing unrelated settings.
Record the trigger type explicitly. A scheduled run, an operator’s on-demand action and a programmatic request should each have an identifiable monitoring route. Agree what observation will show that the requested operation ran, and where the maintainer can find its result if the expected report is unchanged.
Use the current licence and capacity documentation when assessing the available schedule for the actual account. Choose the desired cadence from the business question and source update process. Keep an expected reporting period separate from a promise that every operation will begin or complete at an exact instant.
Will the chosen trigger produce the expected failure alert?
Microsoft’s data-refresh guide describes the notification boundary. By default, refresh-failure emails go to the semantic model owner. Additional recipients can be specified for scheduled-refresh failure notifications. Identify the responsible owner and an appropriate support recipient for the actual arrangement.
The documented failure-notification recipients must have accounts in the Microsoft Entra tenant. Confirm that the intended contacts fit that requirement before relying on an external email address. Record the recipient configuration with the monitoring plan, without copying credentials or unnecessary personal information into a shared report.
On-demand and programmatically triggered refreshes do not trigger the documented email notifications. This matters when replacing a schedule with an automation flow: the monitoring requirement still needs an explicit implementation. Ask the maintainer to demonstrate the actual result and failure path for that trigger rather than carrying over the scheduled-email assumption.
Assign the response decision as well as the notification destination. The recipient should know where to inspect the failure, who can investigate the connection and who decides whether the affected report remains suitable for use. An unattended inbox or an unclear ownership boundary leaves the operating question unresolved.
What should refresh history and report checks establish?
For attempts included in refresh history, Power BI shows the status, start time, duration and error message. Keep the relevant attempt reference and observation with the investigation. Compare the history with the trigger record and the expected source update so another maintainer can reconstruct what happened.
For Power BI service refreshes other than public XMLA, warnings can appear in refresh history. Include warnings in the review instead of stopping at the word Completed. Ask the report owner to inspect the affected result and decide which issue needs correction before the output supports the intended business decision.
Power BI can deactivate a refresh schedule after consecutive failures or an unrecoverable configuration error. If a schedule is disabled, investigate the underlying issue through the documented settings and history before re-enabling it. Retain the correction and the subsequent observation so the recovery is understandable to the next operator.
The original worksheet below separates the trigger, monitoring and approval evidence. Complete it for each report that the automation is intended to support.
| Decision | Evidence to retain | Question for the responsible person |
|---|---|---|
| Trigger | Schedule, on-demand or programmatic route | What initiated this attempt? |
| Connection | Actual source and gateway arrangement | Who can investigate access or connectivity? |
| Monitoring | History and trigger-specific failure path | How will a failure become visible? |
| Result | Source period and representative report check | Does the output answer the intended question? |
| Exception | Warning or failure with assigned owner | Who decides whether the report can be used? |
| Business action | Separate approval requirement | What authorises the downstream action? |
Keep the business-action row independent of a successful refresh. If a report informs a stock adjustment, payment review or another consequential action, define the authorised decision and evidence through the organisation’s own process. The worksheet is a proposed control model, not a claim that refresh automatically provides business approval.
A refresh initiated through the public XMLA endpoint appears in refresh history only when it completes all stages successfully and retrieves new source data.
For public XMLA refreshes, warnings appear in the XMLA response rather than being logged in Power BI refresh history.
For REST-triggered refreshes, warnings are logged in refresh history, but the Get Refresh History and Get Refresh Execution Details REST APIs omit warnings from their responses.
Original scheduled-versus-programmatic failure exercise
Prepare a hypothetical management report in an authorised test arrangement using controlled sample data. Record the intended source period, the semantic model and the owner of the reporting decision. Include both a scheduled-refresh route and a proposed programmatic route only where the team has an approved way to exercise them.
First, inspect the scheduled route’s recipient settings and history. Use an approved, reversible failure scenario selected by the responsible administrator. Record whether the expected failure evidence and notification reach their intended destination. Keep the observed result with the specific trigger that produced it.
Next, identify the actual programmatic trigger and whether it uses a Power BI REST API or the public XMLA endpoint. Retain the trigger configuration, available request reference, response and error evidence separately from refresh history. Examine that route against the documented email and warning-observation exceptions. Ask the implementer to show its separate monitoring and error-handling arrangement. Record what the proposed workflow would do when the refresh request fails, and distinguish that proposed response from any result actually demonstrated during the exercise.
Then inspect a sample Completed result with its available warnings and representative report values. Have the report owner compare the displayed period and selected calculation with the approved source sample. Record any mismatch for investigation before the result is used to support the fictional downstream decision.
Finally, ask a second operator to follow the retained evidence from the trigger and its response, through any applicable refresh-history entry, to the report check. They should be able to identify the response owner and the separate approval boundary without relying on an undocumented explanation. Revise the handover wherever a missing reference makes that path unclear.
Keep the tested configuration and monitoring responsibilities with the automation handover. When a trigger, connection or recipient changes, review the affected worksheet row and repeat the relevant check. This preserves a practical route for investigating both missing data and missing alerts as the reporting arrangement evolves.
Use the business-automation workflow guide for wider failure handling and approval selection. Keep those workflow decisions separate from the Power BI refresh and warning evidence checked here.
For related work, see custom software and integrations and managed hosting. Get started with your report’s data route, refresh trigger and exception-handling requirement.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.