Forum Discussion
Dataflow refresh fails with status code 403 storageAccess when run from power automate.
Hi All,
I have a Gen1 Dataflow in a Premium PPU Workspace that fails with status code 403 after about 50 to 70 minutes of execution when run from Power Automate with 'Refresh a dataflow'. The dataflow runs OK when refreshed manually.
Error: PipelineException: Downstream service call to url 'https://wabi-canada-central-b-primary-redirect.analysis.windows.net/metadata/v201606/cdsa/dataflows/b2e8f2dd-658a-45de-b52a-96d352062012/storageAccess' failed with status code 403.: MashupValueException. RootActivityId = b6ad9bed-01c0-4070-8e34-c3720da61775.Param1 = PipelineException: Downstream service call to url 'https://wabi-canada-central-b-primary-redirect.analysis.windows.net/metadata/v201606/cdsa/dataflows/b2e8f2dd-658a-45de-b52a-96d352062012/storageAccess' failed with status code 403.: MashupValueException Request ID: 24a9300c-bbd9-45ba-9cb2-3bbfaaa3770f.
I am running the dataflow as the owner of the workspace.
The dataflow accesses previously run dataflows data only.
I have refreshed the credentials in the dataflow also.
The power automate action 'Refresh a dataflow' connection reference is mapped to the account that is the owner account.
Any ideas or where I can get more detailed logs?
Thanks
4 Replies
- benibix
Resolver I
ShafiUllah-bc and jubinsoni already cover the logs and the token theory, so here's one extra test that splits the cause in two. Add a scheduled refresh to the same dataflow, at a time when nothing upstream is refreshing, and let it run its full 50 to 70 minutes. A scheduled refresh never goes through Power Automate. If it finishes and only the flow run dies with the 403, the problem sits in the flow's path and not in the dataflow or its linked sources. If the scheduled run fails too, look at the dataflow and its sources first. Either result is worth adding to the support case next to the Request ID and RootActivityId. I can't see your tenant, so this narrows it down but doesn't diagnose it.
- ShafiUllah-bc
Hi PascalGervais,
I would first separate a failed refresh request from a refresh that starts successfully and fails later inside the dataflow. The downstream storageAccess error does not, by itself, establish that the Power Automate connection token expired. The 50 to 70 minute duration is useful evidence, but not proof of token expiry.
For a controlled comparison, run the automated refresh only after every upstream dataflow has completed, with no overlapping refreshes. Compare that run with a successful manual run against the same upstream state.
In the dataflow's Refresh history, download the CSV for both runs. Compare the failing entity or partition, start and end times, and the detailed Error column. Microsoft documents these per-entity details; they are more useful here than the overall 403 alone.
Also check whether the Power Automate refresh action fails immediately or succeeds before the dataflow later fails. Include that distinction, the flow run ID, the two refresh logs, and your existing Request ID and RootActivityId in the support case.
Since this is PPU, the documented Pro dataflow limits of two hours per entity and three hours per dataflow do not explain this failure. I would collect the comparison before changing the authentication approach or splitting the dataflow solely to stay below an assumed one-hour limit.
- maruthisp
Super User
Hi PascalGervais,
The 403 StorageAccess error usually indicates a permission or authentication issue when Power Automate tries to trigger the dataflow refresh.
I would suggest checking the following:
- Refresh the dataflow manually in Power BI Service. If it works, the issue is likely related to the Power Automate connection or its permissions.
- In Power Automate → Connections, check the Power BI connection and re-authenticate it.
- Make sure the account used by Power Automate has Member, Contributor or Admin access to the workspace containing the dataflow.
- Verify that the dataflow's source credentials are valid. If the workspace uses Azure Data Lake Storage, also check the storage permissions.
If the manual refresh works but Power Automate still returns 403, try recreating the Power BI connection in the flow using an account with the required workspace permissions.
Hope this helps!
Best Regards,
Maruthi
LinkedIn - http://www.linkedin.com/in/maruthi-siva-prasad/
X - Maruthi Siva Prasad - (@MaruthiSP) / X 
jubinsoniMemorable Member
Hi PascalGervais,
The detail that stands out is that the same dataflow completes when refreshed manually but fails with a 403 after roughly 50 to 70 minutes when started from Power Automate. A permission problem that you had at the start of the run would fail immediately, so a failure after about an hour suggests something that expires during the run, most likely the credential or token used by the trigger rather than the dataflow definition. I can't confirm that from the error alone, so here is how I would test it and what to collect.
Why a long run can end in a 403
Possibility Why it fits your symptoms How to check Token lifetime of the triggering connection Manual refresh and the Power Automate action authenticate differently, and a run that lasts an hour can outlive the token Compare the failure time across several runs; if it is always close to the same elapsed time, expiry is likely Conditional access or sign-in frequency policy Policies on the owner account can invalidate sessions after a fixed period Ask your Entra admin to check sign-in logs for the account at the failure time Downstream linked dataflow call Your dataflow reads other dataflows, and the 403 is reported as a downstream service call Check the linked dataflows were not being refreshed or edited by someone else at the same time, and that the account still has access to them Ownership or credential change You refreshed the credentials, which suggests this was already suspected Confirm the connection reference in the flow uses the same account, and that it was re-authenticated after the last password or MFA change Where to find more detail
- In the workspace, open the dataflow's refresh history and download the refresh log for the failed run; it lists the entity that was running when the failure happened.
- Keep the Request ID and RootActivityId from the error, since Microsoft Support will ask for them.
- In Power Automate, open the run history for the flow and note exactly when the action started and when it failed.
Ways to avoid the long single run
Option Notes Split the dataflow into smaller dataflows and chain the refreshes Each run finishes well inside an hour; the flow calls them one after another Trigger the refresh through the REST API with a service principal Avoids tying the run to a user token; needs the tenant settings for service principals to be enabled Reduce the work per run Check whether a few entities account for most of the time and move them to a separate dataflow If the failure always lands at the same elapsed time, you have strong evidence for token expiry and can raise it with support with that pattern, the Request ID and the flow run ID.
So my overall approach would be:
1. Record elapsed time at failure over several runs 2. Check sign-in logs and conditional access for the owner account 3. Download the dataflow refresh log for the failing entity 4. Split the dataflow or use a service principal to shorten dependence on one token 5. Open a support case with Request ID and RootActivityIdAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
