Gate Report Distribution on a Verified Power BI Refresh

Never distribute stale or half-refreshed reports. Sending a report while its dataset is mid-refresh, or after a refresh silently failed, is worse than sending nothing: recipients act on wrong numbers. This blueprint makes the refresh itself the gate. io.kestra.plugin.powerbi.RefreshGroupDataset runs with wait: true, so the flow only reaches the distribution step when Power BI has confirmed a completed refresh; a failed refresh stops the flow before anything leaves.

How it works

1. refresh_dataset (io.kestra.plugin.powerbi.RefreshGroupDataset) authenticates with the Azure AD service principal and triggers the refresh, polling every 10 seconds for up to 30 minutes. Because wait: true, a refresh that ends in a failed state fails the task, and Kestra's sequential execution means nothing after it runs. The gate needs no explicit condition, task failure is the gate.
2. distribute_report (io.kestra.plugin.core.log.Log) stands in for the real distribution, for example a report export to PDF, an email send, or a subflow call that fans out to several recipient lists. It only ever executes on top of a verified refresh.
3. notify records the successful send in Slack together with the refresh status, giving an audit trail that every distributed report sat on fresh data.
4. The errors block tells the team the gate closed: the refresh failed and distribution was deliberately withheld.

What you get

• A hard guarantee: no execution path exists where distribution runs on a failed or unfinished refresh.
• Withheld beats wrong: on failure, recipients get nothing instead of stale numbers, and the team gets an alert.
• An audit trail pairing every distribution with the refresh status it was gated on.
• A distribution placeholder you can swap for any export, email, or subflow without touching the gate.

Who it's for

• Teams emailing scheduled report exports to executives, customers, or regulators.
• BI owners burned by a report snapshot taken mid-refresh.
• Anyone whose distribution currently runs on a timer that just hopes the refresh finished first.

Why orchestrate this with Kestra

Power BI subscriptions send on a schedule regardless of whether the last refresh worked. Kestra sequences the two operations with a verified wait in between, so ordering is guaranteed rather than assumed, the withheld case is alerted rather than silent, and every send is auditable against the refresh that preceded it.

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 behind the report.
• A Slack incoming webhook for the audit trail and withheld-distribution 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 confirm the distribution log line and the Slack audit message.
4. Swap distribute_report for your real export or email step.

How to extend

• Replace the placeholder with a real distribution, for example an email task carrying an exported file, or an HTTP call to the Power BI export API.
• Chain distribution as a subflow with io.kestra.plugin.core.flow.Subflow, so one gated refresh feeds several recipient-specific distribution flows.
• Put the refresh behind a Schedule trigger to gate a recurring send, as shown in the morning refresh blueprint.
• Add a retry policy on the refresh so transient failures retry before the gate closes, as shown in the retry policy blueprint.

Links

• Power BI plugin documentation
• Subflow task documentation