Forum Discussion
Helper IRefresh Errors
Thank you for clarifying your requirement. Since management needs reports at a fixed time daily, you could use Azure Data Factory to orchestrate the semantic model refresh, with retries and status monitoring before triggering report delivery.
Please note that Power BI automatically disables scheduled refresh after four consecutive failures and this threshold cannot be changed. An API-driven refresh workflow can provide more control over retries and monitoring, but it cannot guarantee uninterrupted refreshes.
For details, see Microsoft's asynchronous refresh documentation.
https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-scheduled-refresh
I hope this helps!
Memorable MemberHi MichelleRoberts,
Short answers first, then a setup that avoids the problem:
Do I need a refresh schedule? Yes, for Import models. A subscription only renders the report; it never refreshes data. Why does the schedule turn itself off? The service disables a scheduled refresh after several consecutive failures. Why "transient" errors every morning? Often the refresh runs while the ADF load is still writing (or right after), or many models refresh at the same minute.The more reliable pattern is to stop guessing the time and chain the steps: let the ADF pipeline refresh the model when the load finishes, and let the subscription fire after the refresh.
1. Refresh from ADF at the end of the pipeline (Web activity, using a service principal or managed identity that has access to the workspace):
POST https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}/refreshes Body: { "retryCount": 2 } -> then poll GET .../refreshes?$top=1 until status = Completed / Failed2. Remove (or keep as a late backup) the fixed schedule in the semantic model settings, so the model is not refreshed in the middle of the load.
3. Subscription "after data refresh": when editing the subscription, pick the frequency option that sends after the semantic model refreshes (sent at most once a day), instead of a fixed clock time. Then the email always goes out with the data that was just loaded.
If you keep a time-based schedule for now, at least spread the models a few minutes apart and leave a buffer after the ADF pipeline's typical end time, and check Refresh history for the exact error text to confirm whether it is timing or credentials.
So my overall approach would be:
ADF load finishes -> ADF Web activity triggers semantic model refresh (with retry) -> Subscription set to send after data refresh -> Fixed schedule removed or kept only as late backupAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.