Refresh a Power BI Dataset Right After the Warehouse Load

End the "dashboard shows yesterday" problem. When the warehouse load and the Power BI refresh live on separate schedules, executives open reports that lag the data by hours. This blueprint chains io.kestra.plugin.powerbi.RefreshGroupDataset directly after the load step, so the semantic model refreshes the moment new data lands, and Slack confirms it.

How it works

1. load_warehouse (io.kestra.plugin.core.log.Log) stands in for your real ELT step. Swap it for your actual load, for example the dlt REST API to DuckDB blueprint or the federated Trino query blueprint, keeping the rest of the chain unchanged.
2. refresh_dataset (io.kestra.plugin.powerbi.RefreshGroupDataset) authenticates with an Azure AD service principal (tenantId, clientId, clientSecret), triggers a refresh of the dataset in the given workspace, and polls every 10 seconds for up to 30 minutes because wait: true. If Power BI reports the refresh as failed, the task fails and the flow stops.
3. notify posts the final refresh status to Slack, so the team knows the dashboards reflect the data that just landed.
4. The errors block posts a distinct Slack alert when either the load or the refresh fails, naming the flow and execution.

What you get

• Dashboards that update minutes after the data lands instead of on a blind timer.
• A refresh that is verified, not just requested, because the task waits and fails on a failed refresh state.
• A Slack confirmation carrying the actual refresh status returned by the Power BI API.
• A failure alert so a broken refresh never hides behind a green load.

Who it's for

• Data engineers tired of coordinating warehouse schedules with Power BI's scheduled refresh windows.
• BI teams whose stakeholders ask "is this current" before trusting a report.
• Anyone replacing a manual "load finished, now click refresh in the service" routine.

Why orchestrate this with Kestra

Power BI's built-in scheduled refresh runs on a timer that knows nothing about your pipeline. Kestra makes the refresh an explicit step in the same flow as the load, so it runs exactly once per load, waits for a verified completion, feeds its status into notifications, and leaves a full execution history for every 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) from the Power BI service URLs.
• A Slack incoming webhook for confirmations and alerts.

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 and check the Slack message reports a completed refresh.
4. Swap load_warehouse for your real load step.

How to extend

• Replace the placeholder with a real load task, for example io.kestra.plugin.dlt.Run or io.kestra.plugin.jdbc.trino.Query.
• Trigger this flow from your existing ingestion flow with a Flow trigger, keeping load and refresh in separate flows but still chained.
• Refresh several datasets after one load, as shown in the multi-dataset refresh blueprint.
• Add a retry policy for flaky gateway sources, as shown in the refresh retry policy blueprint.

Links

• Power BI plugin documentation
• Power BI REST API refresh documentation