Weekday Morning Power BI Refresh with Failure Paging

The worst way to learn a refresh failed is from an executive staring at stale numbers in a 9am meeting. This blueprint runs io.kestra.plugin.powerbi.RefreshGroupDataset every weekday at 06:30, waits for a verified completion, and splits the outcome into two channels: a quiet Slack confirmation on success, and an immediate page to the BI owners on failure.

How it works

1. A Schedule trigger (disabled by default) fires at 06:30 on weekdays, before the workday starts.
2. refresh_dataset (io.kestra.plugin.powerbi.RefreshGroupDataset) authenticates with an Azure AD service principal (tenantId, clientId, clientSecret) and triggers the refresh. Because wait: true, it polls every 15 seconds for up to 45 minutes and fails the flow if Power BI reports the refresh as failed or the wait window is exceeded.
3. notify posts the completed status to Slack, giving the team a daily heartbeat that reports are current.
4. The errors block posts a distinct, urgent Slack message the moment the refresh fails, pointing at the Power BI refresh history for the failing table or partition.

What you get

• A refresh that runs before anyone needs the reports, with a verified completion instead of a fire-and-forget request.
• A clear split between confirmation and alert, so failures stand out instead of drowning in routine messages.
• Time to fix problems: a 06:30 failure alert leaves a two hour head start before the first meetings.
• A full execution history of every morning refresh, including how long each one took.

Who it's for

• BI owners accountable for reports being fresh when the business logs on.
• Data teams replacing the Power BI scheduled refresh with an observable, alertable equivalent.
• Anyone who has been asked "why does the dashboard show yesterday" one time too many.

Why orchestrate this with Kestra

Power BI's own scheduled refresh can send a failure email, but it disappears into inboxes and offers no execution history, no polling control, and no way to chain follow-up actions. Kestra gives the same schedule a verified wait, routed notifications, per-execution logs, and a place to later chain loads, checks, or exports around the refresh.

Prerequisites

• An Azure AD app registration with Power BI API permissions granted, authenticating through the OAuth 2.0 client credentials flow.
• Service principal access enabled for Power BI in the admin portal, and the service principal added to the target workspace.
• The workspace id (groupId) and dataset id (datasetId) of the model to refresh.
• A Slack incoming webhook for confirmations and paging.

Secrets

• AZURE_TENANT_ID: Azure AD tenant id.
• AZURE_CLIENT_ID: Azure AD application (client) id.
• AZURE_CLIENT_SECRET: Azure AD client secret.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the four secrets to your Kestra namespace.
2. Replace groupId and datasetId with your workspace and dataset ids.
3. Execute the flow manually once and confirm the Slack message arrives.
4. Set disabled: false on the weekday_mornings trigger and adjust the cron to your timezone needs.

How to extend

• Point the error webhook at a dedicated alerts channel with a different SLACK_WEBHOOK_URL secret so pages never mix with confirmations.
• Chain the refresh after your actual warehouse load instead of a timer, as shown in the refresh after ELT blueprint.
• Add a retry policy before paging, as shown in the refresh retry policy blueprint.
• Refresh several datasets in one morning run, as shown in the multi-dataset refresh blueprint.

Links

• Power BI plugin documentation
• Power BI refresh troubleshooting documentation