Run Power Apps Actions with Elevated Permissions via Power Automate, from Reza Dorrani

A Power Automate flow’s connections belong to whoever configured them, not to whoever happens to trigger the flow. Reza Dorrani uses that fact to let a Power Apps user perform actions - creating a SharePoint item, updating a Dataverse record - that they personally have no permission for.

🔑 Important: this technique works with the PowerApps V2 trigger specifically.

Quick answer: Build the flow’s actions (the SharePoint “Create item”, the Dataverse update, whatever the restricted operation is) using connections owned by a service account with the necessary permissions, and trigger that flow from Power Apps with the PowerApps V2 trigger. The flow runs with the service account’s permissions regardless of which end user in the app triggered it - the app user never needs the underlying access themselves.

Why this works

When a flow runs, each action uses the specific connection configured for it at design time - a SharePoint connection is tied to whichever account was signed in when that connection was created, independent of who or what triggered the flow’s run. A flow triggered from Power Apps via the PowerApps V2 trigger still executes with its own configured connections, not with the calling user’s identity. That’s what makes “elevated permissions” possible: build the flow with a service account’s connections, and every user of the app effectively gets that service account’s access for exactly the operations the flow performs - nothing more.

The setup

1. Prepare a service account with the permissions the operation actually needs (write access to a restricted SharePoint list, update rights on a Dataverse table, and so on).
2. Build the flow’s connections using that service account - sign in with it when creating the SharePoint/Dataverse/other connection the flow’s actions use.
3. Trigger the flow from Power Apps with the PowerApps V2 trigger, passing whatever data the action needs.
4. The end user never touches the restricted resource directly - they only interact with the Power Apps screen and trigger the flow, which does the privileged work on their behalf.

Why this beats a child-flow workaround

Before the PowerApps V2 trigger matured, a common pattern was a parent flow (running as the calling user) invoking a child flow (running as the service account) to reach the elevated permissions. Triggering the service-account-owned flow directly from Power Apps removes that extra hop - one flow, one set of connections, easier to read and debug.

What to watch for

• Validate input inside the flow. Since the flow now acts with elevated rights regardless of who calls it, the flow itself - not the end user’s permissions - is your only remaining safety check. Add condition checks before the privileged action runs.
• Audit what the service account can reach. Give it only the permissions the specific operations need, not broad admin rights, so a flow bug can’t do more damage than intended.
• Log elevated actions if the operation is sensitive enough to need an audit trail - the flow’s run history alone may not be sufficient for compliance purposes.

🛠️ FAQ

Can Power Apps users run actions they do not have permission for?

Yes. A flow using the PowerApps V2 trigger runs with the connections it was built with - typically a service account’s - regardless of which end user in the app triggered it, so the user effectively gets that service account’s access for the specific operations the flow performs.

Does this elevated-permissions approach work with any Power Apps connector?

This specific pattern is described for the PowerApps V2 trigger; check the trigger and connector versions your environment supports before relying on it.

Do I still need child flows to handle elevated permissions in Power Apps?

Not for this pattern - triggering a service-account-owned flow directly from Power Apps with the PowerApps V2 trigger is a simpler alternative to the older parent/child flow workaround.

What does the service account need for this setup?

Only the specific permissions the flow’s actions require on the target systems (SharePoint, Dataverse, or elsewhere) - keep it scoped to what’s actually needed rather than broad administrative access.

🔗 Related Tips

🔸 #PowerPlatformTip 126: ‘User Context for Automated Tasks’ - the opposite scenario, running a flow in each user’s own context instead of a service account.

🔸 #PowerPlatformTip 98: ‘Secure Inputs, Secure Outputs’ - mask the service-account credentials this impersonation pattern relies on in the flow’s run history.

---

You can see this video here on my blog because I have rated this video with 5 stars in my YouTube video library. This video was automatically posted using PowerAutomate.