Power Automate will not refresh Power Query in Excel, even when the flow says it worked

What happens when Power Automate runs a refresh script on an Excel file?

I should give a bit of background first. An Office Script is a small script written in TypeScript that runs against a workbook stored in OneDrive or SharePoint. You can run one yourself from the Automate tab in Excel. You can also hand it to Power Automate, which is Microsoft's tool for running steps on a schedule or when a specific event happens.

When a flow runs the script, your own Excel is not doing the work. Microsoft says Power Automate runs scripts on your behalf in independent Excel sessions. The workbook might be closed while this happens. So there is no window, no person, and no Refresh button anywhere near it, and some methods behave quite differently in that environment.

The troubleshooting page lists those differences in plain tables. I look at the part that matters for refreshing data, which sits next to two methods that fail loudly. That helps you see the difference between a script that actually breaks and a script that quietly does nothing.

So a Power Query that reads a CSV in SharePoint, a SQL Server table, or another Excel file is not refreshed by that call when a flow runs it. The script still ends normally, and the flow still reports that the step succeeded.

The one source that does refresh is Power BI. A table or PivotTable in your workbook might connect to a Power BI semantic model, which is just the published data model behind a Power BI report. If so, the same script call refreshes it directly from the flow. I come back to that below, because it is the cleanest fix for some teams.

Why does the flow say it succeeded when nothing refreshed?

In software there is a big difference between failing and doing nothing. When a step fails, it throws an error, the run turns red, and Power Automate can send you a failure email or run a different branch of the flow. When a method does nothing and returns normally, there is nothing to catch. So every alert you set up just waits for an error that never comes.

Microsoft publishes flow limits in its platform limits for Office Scripts, and these limits do raise errors when you hit them. You get an error when you go past 1,600 Run script calls a day per user, or when a script runs into the 120 second timeout. The refresh limit is the only one of these that stays completely quiet.

That is also why the usual checks do not help you find the problem. People open the run history and see the Run script step marked as succeeded. Then they look at the file in OneDrive and see a new version from the exact time the flow ran, and they reasonably decide the data refreshed.

But the new version proves nothing either. Microsoft's notes for the Excel Online (Business) connector explain that a file may be modified, with a new version in its version history, even when a read-only action runs. This happens because of how the connector saves in the background. So a new version only tells you the connector touched the file, but it does not mean any query ran.

You can see how often this catches people in Microsoft's own Q&A forum. A user there describes a Run script step that tests as successful, but their Power Query table never updates. The answer there points to the exact same documented limit.

A green run and a new file version are not proof. The only real proof is a value the query itself writes when it actually runs.

How can you check whether Power Query really refreshed?

You should put the time inside the query. Power Query has a function called DateTime.LocalNow, which returns the current date and time at the exact moment the query runs. You add it as the last step of the query you care about. Every real refresh stamps a new time into the table, while a refresh that never happened just leaves the old time sitting there.

1. 01
   Open the query and add a custom column

   In the Power Query editor, go to Add Column, then Custom Column, name it Refreshed At, and use the formula = DateTime.LocalNow(). Keep it as the last step. That way it only gets a new value when everything above it has run properly.
2. 02
   Load it with the rest of the table

   Close and load as usual. The time now sits beside your data in the same table. This means the data and the time can only refresh together.
3. 03
   Refresh once by hand and note the time

   Press Refresh in Excel and watch the column change. That is your baseline. It proves the column works before you trust it to catch any flow issues.
4. 04
   Run the flow, then look at the column again

   If the time did not move, the flow did not refresh the query, regardless of what the run history says. If it moved to the time your flow ran, the query really ran.

There is one detail to know before you compare times. Microsoft's page for the function says the value depends on where the query runs, so Excel on your PC gives your local time, while Power Query Online gives UTC, which is the universal time servers use. The troubleshooting page adds that Power Automate always uses UTC. So if two times are a few hours apart, check the time zone before you decide anything is broken.

If you want this check to run on its own, I suggest adding a second Run script step after the refresh. This step can read the Refreshed At value from a named sheet and return it to the flow, and then you can email yourself that single line. Reading a cell works fine in a flow because the limit only affects refresh methods and things that depend on a cursor. So the stale time lands straight in your inbox where you can actually see it.

Which ways of refreshing Excel actually work with nobody at the desk?

Once you accept that the Run script step cannot run the query, you have to ask a different question. Something has to actually run the Power Query engine. Every option that does this needs a machine or a service that stays awake, so I will show you the routes and the conditions they carry.

When is Excel's own refresh timer enough?

If someone opens the file every morning anyway, you might not need a flow at all. You can just open desktop Excel, go to Queries and Connections, right-click your query, and choose Properties. From there you tick Refresh data when opening the file, or you tick Refresh every so many minutes. You can read about both options on Microsoft's page about refreshing an external data connection. But the catch is plain: Excel has to be open for either of these to work.

Excel for the web can also refresh many Power Query sources like SharePoint files and folders and SQL Server when someone clicks Refresh All. But there are limits. Microsoft has a list of Power Query data sources in Excel versions, and it says the web version does not refresh queries loaded to the Data Model. It also does not refresh workbooks saved in a third-party cloud, or sources that need an on-premises data gateway.

How does the Power BI route work for an Excel file?

You can also move the query out of the workbook and into Power BI. You just build the exact same Power Query steps in Power BI Desktop, publish them as a semantic model, and set a scheduled refresh in the service. Microsoft's data refresh documentation says you get eight scheduled refreshes a day on shared capacity, and up to 48 on Premium, Premium Per User or Fabric capacity. If Power BI cannot reach a source directly, like a local database or a file on your network, you will need to set up a gateway connection first.

Then you just connect Excel to that model. You go to the Insert tab, choose PivotTable, and click From Power BI, so the workbook holds a live connection instead of its own local copy of the query. This is the only time the Run script refresh actually works inside a flow, because now the source is Power BI. Microsoft's page on the Power BI semantic model experience in Excel says your tenant admin must allow semantic models in Excel with a live connection, and you must have Build permission on the model.

If you decide to start the refresh from a flow using the Power BI connector's Refresh a dataset action instead of a schedule, you need to remember two things. The REST API behind it gives an answer of 202 Accepted, and this only means the request was accepted, so it does not mean the refresh finished. You should always look at the model's refresh history before you trust the numbers. Also, on shared capacity these requests count toward the same eight a day limit. This is the exact same service that makes a weekly Power BI PDF send itself.

What about a desktop flow that opens Excel?

Another option is Power Automate for desktop. It can open the workbook in real Excel on a real machine, run a macro to refresh it, and then save and close. The query really runs here because it uses genuine desktop Excel. But for unattended runs, Microsoft's page on running unattended desktop flows says you need the Power Automate Process plan. You also need a machine with all users signed out, and the flow will not run if there is a locked Windows session on it.

Two things go wrong with this desktop route. The first problem is timing. Chris Webb explains in a post on his BI blog that closing Excel right after the macro fired actually closed it before the query had time to finish. You can fix this by unticking Enable background refresh in the query's properties. This setting usually lets a query run in the background while Excel does other things, so turning it off forces the refresh to finish before the macro moves on.

The second problem is dialog boxes. Microsoft has a note on server-side automation of Office that explains how Office is built to stop and ask the user a question in a dialog box. Since nobody is watching the screen, the dialog cannot be dismissed and the thread just hangs there. Test the flow with the file's worst day in mind, like when a source suddenly asks for credentials again.

When is Python the better answer?

Sometimes the result does not need to stay inside Excel at all. You can use a Python script on Windows Task Scheduler to read those same exports, apply the same rules, and write a fresh file or send an email. This method never needs Excel open. The honest cost here is that your Power Query steps will not come with you. Python does not run M, which is the language Power Query writes behind its buttons, so you have to rewrite the logic. I laid out how to choose between the two tools in Power Query or Python first.

Which route should you pick for your workbook?

I always start by looking at where the data comes from and who opens the file, rather than starting from the tool. These five cases cover most of the workbooks people ask me about.

1. 01
   Your data already comes from a Power BI semantic model

   Keep the Run script flow. This is the one case Microsoft documents where a refresh works inside a flow, so here the green tick actually means something.
2. 02
   A person opens the workbook every morning

   Tick Refresh data when opening the file in desktop Excel and just drop the flow. The refresh will happen while a person is looking at the screen, so someone will actually see the error if a source breaks.
3. 03
   People only read the numbers

   Move the query into a Power BI semantic model and use a scheduled refresh. Your readers can get a report or a PivotTable connected to the model, and the service handles all the refreshing.
4. 04
   The output has to be this exact Excel file

   Use a desktop flow on a machine that always stays on. Just remember to turn background refresh off and keep the Refreshed At column in your query.
5. 05
   The output leaves Excel as files or emails

   Write the logic in Python and run it on a schedule. If people still want an Excel workbook, you can just let Power Query read the clean file that your script writes.

Whichever route you choose, I stick to the rule from automating an Excel report. You should always build the version that fails loudly. A refresh that reports success without actually refreshing is a quiet kind of failure. It belongs to the same family of errors that look perfectly fine until a spreadsheet audit traces them back.

So if your flow refreshes Power Query from anything other than Power BI, replace the Run script step with a route that really runs the query, and keep the Refreshed At column either way.