Trigger Actions After a Power BI Dataset Refresh

Power BI does not give you a native "when a semantic model refresh completes" trigger in Power Automate. You can still run something the moment a refresh finishes. Either poll the refresh status through the REST API, chain the steps in a Fabric pipeline, use a data-driven alert as a workaround, or use a report automation tool that waits for the refresh and then runs your reports. This guide walks through each option, what it costs you in setup and reliability, and how to choose.

TL;DR

• Power Automate's Power BI connector has no dataset-refresh-completed trigger. It does have one for dataflows.
• The "Refresh a dataset" action only confirms the request was accepted. It does not wait for the refresh to finish, so you must check the status yourself.
• The dependable DIY pattern is: start the refresh, loop on refresh history or the status endpoint, then branch on Completed or Failed.
• Add a timeout, retry limit, failure alert and logging, or the chain will fail silently.
• If you want the refresh-then-deliver sequence without building and maintaining flows, PBRS can run your reports after a dataset refresh.

Table of Contents

• Why there is no "after refresh" trigger
• Your options at a glance
• Pattern 1: Start the refresh, then poll until it finishes
• Pattern 2: Refresh a semantic model after a dataflow
• Pattern 3: The data-driven alert workaround
• Pattern 4: Start a refresh from a button, a file or an API call
• Permissions and limits to check first
• Make the chain reliable
• Perspective: refresh and delivery belong in one workflow
• Run your reports after the refresh with PBRS
• Which approach should you choose?
• FAQ
• Sources

Why there is no "after refresh" trigger

Most people expect to find a trigger called something like "When a dataset is refreshed" next to the other Power BI triggers. It is not there. A published pattern guide from Excel Goodies states that Power Automate has no built-in dataset-refreshed trigger, and that chaining means polling the refresh status through the REST API or running refreshes in sequence and assuming a known completion window.

The second half of that sentence is the trap. Assuming a completion window ("the refresh usually takes 20 minutes, so wait 25") works until the night the source database is slow. Then your downstream step runs on stale data and nobody notices.

There is one real trigger close to what you want. Tim Weinzapfel notes that the Power BI connector has no dataset trigger, but it does offer "When a dataflow refresh completes". That trigger fires whether the refresh succeeded or not, and it returns the refresh status, start time and end time. We come back to it below.

Another route is a third-party automation platform. Pipedream, for example, lists a "Dataset Refresh Completed" trigger for Power BI. It polls on a configurable timer and emits an event you can send to a webhook. That works if you already run Pipedream, but it adds another platform to secure and monitor.

Your options at a glance

Pattern 1: Start the refresh, then poll until it finishes

This is the most general approach, and the one most blog posts converge on. The reason it is needed is how the API behaves. Wicked Smart Data explains that a POST to the dataset's refreshes endpoint queues the refresh and immediately returns HTTP 202 Accepted. The refresh runs in the background, so your flow has to check the status until it reaches a terminal state: Completed, Failed or Cancelled.

The steps in Power Automate look like this:

1. Start the refresh. Use a scheduled cloud flow (or whatever event you need) and the "Refresh a dataset" action, or call the refreshes endpoint directly.
2. Wait before the first check. Chris Webb recommends a 30-second delay before the first status check. With the Enhanced Refresh API, Power BI returns a refresh ID in the x-ms-request-id header, and you pass it to the Get Refresh Execution Details endpoint.
3. Loop with Do until. In Chris Webb's pattern, the loop ends once the status is no longer Unknown, which means the refresh has finished.
4. Branch on the outcome. A Condition action sends an email. If the status is Completed, the refresh succeeded. Any other value tells you at a high level what went wrong.
5. Run your next step only on the success branch.

A simpler variant uses the "Get Refresh History" action. One published build checks every 5 minutes for up to 12 iterations, posts a Teams adaptive card on success and alerts an admin with error details on failure.

Mind the polling interval

It is tempting to check every few seconds. Don't. Wicked Smart Data advises waiting at least 30 seconds between status checks, and warns that hammering the endpoint every 5 seconds can get your tenant throttled without making the refresh finish any sooner. For a model that takes 20 minutes, a check every 60 seconds is plenty.

Use "Configure run after"

If you stay with the plain "Refresh a dataset" action, you can still handle both outcomes. A Stack Overflow answer describes adding two parallel actions and setting "Configure run after" on each, one for success and one for failure. Keep in mind what that tells you: it reflects whether the request was accepted, not whether the data finished loading. For anything that depends on fresh data, poll the refresh history.

Pattern 2: Refresh a semantic model after a dataflow

This is the most common version of the question, and the one with a real trigger. The report only has current data when both the dataflow and the semantic model have refreshed successfully, so the semantic model has to wait for the dataflow.

In Power Automate

Lasse Malo describes a zero-code pattern: refresh the dataflows, add a "When a dataflow refresh completes" trigger after each refresh action (it checks every 3 minutes by default), and use a Condition with Run After settings to wait for all dataflows. Only then refresh the semantic model.

Two details matter here:

• The refresh status from that trigger is always Success, Failed or Cancelled. If one dataflow failing should not block the semantic model, use the rule "is not equal to Cancelled" so the model still refreshes.
• The trigger works with user access or a service principal, and you need access to the workspace holding the dataflow, according to Data Meerkat.

In a Fabric data pipeline

If you are on Fabric, you may not need Power Automate at all. Reza Rad shows a data pipeline with a Dataflow activity followed by a Semantic Model Refresh activity, with the dataflow's output state set to successful. You then schedule the pipeline itself, so you no longer schedule the dataflow and the semantic model separately. The order is guaranteed by the pipeline rather than by guessed timing.

Pattern 3: The data-driven alert workaround

This trick avoids the API entirely. It turns a change in a refresh-time value into a Power Automate trigger.

The BI Accountant describes it: create a measure such as UTCNOW()*1 that changes on every refresh, pin it to a dashboard tile, set a data alert that fires when the value is above 0, and choose "Use Microsoft Power Automate to trigger additional actions". PBI Guy documents a similar setup with a tile showing the last refresh time and the "Trigger a Flow with a Power BI Data-driven alert" template.

Know the limits before you rely on it:

• It does not fire more than once per hour, and it does not work when the refresh went through the XMLA endpoint.
• PBI Guy reports a delay of around 5 to 7 minutes between the refresh finishing and the flow starting.

That is fine for a "data is ready" notification. It is not the right tool when a downstream job must start within a minute or when refreshes happen more than hourly.

Pattern 4: Start a refresh from a button, a file or an API call

Sometimes the "trigger" you need is the one that starts the refresh, not the one that follows it.

• From a report button. The Power Automate visual lets users start a flow from a published report, which can call the refresh action. Treat it as a request: the refresh still runs in the background.
• From a file or data change. A SharePoint or Excel change can start the flow. Pop Automation advises that when several files arrive within minutes, you should add a short delay and a check, or trigger on a single "done" file that the upstream process writes last. It also suggests saying "started" rather than "done" in notifications, since the action does not wait for the refresh.
• From an external system. Anything that can make an authenticated HTTP call, such as a cloud function or a storage event, can POST to the refreshes endpoint. In Azure Data Factory or Synapse, endjin recommends first checking whether a refresh is already running (query /refreshes?$top=1), then triggering a new one and polling in an Until loop until the status is no longer Unknown.

For a walkthrough of calling and monitoring the API, see our guide on how to trigger and monitor a Power BI refresh with the REST API.

Permissions and limits to check first

Refresh-triggered flows fail for boring reasons more often than clever ones.

• Account and role. The connection account needs a Power BI license that covers the workspace and permission to refresh the model. Pop Automation says that in practice means Contributor or higher.
• Daily refresh caps. The same source reports that shared-capacity models accept at most eight refresh requests per day, scheduled ones included, while Premium, PPU or Fabric models allow far more. Another published build cites up to 8 refreshes a day with Pro and up to 48 with Premium. Limits change, so confirm the current numbers for your license in Microsoft's documentation. If a trigger can fire many times, it can eat the daily allowance that your schedule needs.
• Gateways. For on-premises sources such as SQL Server, the same build notes that an on-premises data gateway must be installed on a machine that stays running.
• Disabled schedules. Repeated failures can switch scheduled refresh off. If yours stopped, see why Power BI scheduled refresh fails or gets disabled.

Make the chain reliable

A flow that works in a demo and one that survives a year of production differ in the failure handling. Excel Goodies recommends a timeout and retry limit to avoid infinite loops, Teams or email alerts when the chain fails, and logging of the dataset name, start time, end time, status and error message.

In practice that means:

1. Cap the loop. A Do until with no limit will run forever against a hung refresh. Set a maximum count and a timeout, and treat reaching either as a failure.
2. Always have a failure path. One published build puts it plainly: flows without error handling break silently, so every production flow needs at least an email or Teams alert to its owner.
3. Check for a refresh already in progress before starting a new one, as in the endjin pattern.
4. Guard against duplicate triggers. Use the delay-and-check or single "done" file approach for bursts.
5. Log every run so that you can answer "did the 6 a.m. refresh finish before the report went out?" without guessing.

Visibility is the common thread. Teams that pull BI data from operational systems know the pain of not being sure which numbers are authoritative, which is the problem behind TMS BI reporting integration. The same discipline applies to refresh chains: error details and notifications should be easy to find, not buried in a run history nobody opens.

Perspective: refresh and delivery belong in one workflow

We see the same pattern in many Power BI environments. A team starts with a scheduled refresh and a Power Automate flow, then adds a loop to wait for completion, then a second flow for failures, then a third for the email with the PDF. Each piece works. Together they become something one person understands and everyone else is afraid to touch.

Our view is that the refresh and the report delivery are one workflow and should be managed as one. PBRS is built around that idea: it schedules, personalizes, exports and securely delivers Power BI and SSRS reports, and it can run reports after a dataset refresh, so the data your recipients get is the data that just loaded. Data-driven bursting, event triggers, multiple formats and multiple destinations replace the manual steps and the custom scripts.

That does not make flows and the REST API useless. They are the right tools for plenty of jobs. But when the real goal is "the right report, in the right format, to the right person, after the data is ready", we would rather configure that than script it.

Christian Ofori-Boateng

Run your reports after the refresh with PBRS

If your reason for triggering after a refresh is to send or export reports, you can skip building the polling loop. PBRS for Power BI is our on-premises report automation software. It is designed to schedule and deliver Power BI and SSRS reports by email, to cloud or file destinations, and to collaboration tools, in formats such as PDF and Excel, and to run them once a dataset refresh has completed. Our page on how to automatically run Power BI reports after a dataset refresh shows the setup, and the Power BI scheduler page covers scheduling refreshes and reports together.

PBRS is available as a subscription or a perpetual license. When you are ready to see it against your own refresh chain, start from the PBRS overview and request a trial or demo.

Which approach should you choose?

• You only need a notification that data is ready, and hourly granularity is fine. Use the data-driven alert workaround.
• You chain a semantic model after dataflows. Use the "When a dataflow refresh completes" trigger, or a Fabric pipeline if you are on Fabric.
• You start refreshes from outside Power BI. Call the REST API and poll for the terminal state.
• You need refreshed data in recipients' inboxes on a schedule, with personalization and formats. Use a report automation tool rather than assembling flows. Our walkthrough of automating Power BI reports after a dataset refresh goes through it step by step, and a related piece covers making Power BI alerts reliable with nightly refreshes.

Whichever you pick, test the failure path first. Break the credentials on a test dataset and confirm that someone gets a clear message.

FAQ

Is there a "when a dataset refresh completes" trigger in Power Automate?

No. The Power BI connector has no dataset-refresh trigger, although it does have "When a dataflow refresh completes". For datasets, you poll the refresh history or status endpoint, or use the data-driven alert workaround.

Why does my flow continue before the refresh is finished?

The "Refresh a dataset" action only reports that the request was accepted. The refresh itself runs in the background. Add a loop that checks refresh history until the status is Completed, Failed or Cancelled, and only then run the next step.

How often should I check the refresh status?

Wait at least 30 seconds between checks, and about 30 seconds before the first one. Checking every few seconds can get your tenant throttled and does not speed up the refresh. For long refreshes, a check every minute or every 5 minutes is common.

Can I refresh a semantic model automatically after a dataflow finishes?

Yes. In Power Automate, use the "When a dataflow refresh completes" trigger and a condition on its status. In Fabric, build a data pipeline with a Dataflow activity followed by a Semantic Model Refresh activity, and schedule the pipeline.

How do I know if the refresh failed?

Branch on the final status and send a Teams or email alert with the error details on failure. Log the dataset name, start and end time, status and error message so that you can trace problems later.

Sources

• Power Automate patterns for Power BI dataset management, Excel Goodies
• Dataset Refresh Completed trigger, Pipedream
• Automatic Notifications of Successful Power BI Data Refreshes, Power BI Integration
• Building Real-Time Power BI Dataset Refresh Pipelines, Wicked Smart Data
• Calling the Power BI Enhanced Refresh API from Power Automate, Chris Webb's BI Blog
• Automated Power BI Reporting with Power Apps and Power Automate, Helion360
• Power Automate: wait till Power BI dataset refresh completes, Stack Overflow
• Dynamic Dataflow Refresh For Dummies, Power BI Insider
• Dataflows refresh monitoring, Data Meerkat
• Refresh Power BI Semantic Model After Dataflow, RADACAD
• When a Power BI dataset refresh completes trigger in Power Automate, The BI Accountant
• Starting a job after a Power BI dataset has refreshed, PBI Guy
• How to Refresh a Power BI Semantic Model From Power Automate, Pop Automation
• Reliably refresh Semantic Model from ADF or Synapse Pipelines, endjin

Recommended

• Automate Power BI Reports After Dataset Refresh
• Automate and Schedule Power BI Dataset Refreshes and Reports
• Automatically Run Power BI Reports After Dataset Refresh
• Power BI Subscription After Data Refresh: Delivery Workflow