Attended flows have always had an interface problem: the only way to ask a person something mid-run was a stack of modal input dialogs. The new run Power App action replaces that with an actual app — and a two-way channel back into the flow.
Every mature attended automation eventually hits the same wall. The flow gets to a point where a human has to decide something — which of these three matching customer records is the right one, is this invoice actually a duplicate, does the quantity on the scanned form look correct — and the flow needs to ask.
The options up to now were all compromises. Display input dialog chains work but scale badly: five sequential modals, no validation beyond a text box, no way to show the person the document they're being asked about. Picture-in-Picture run mode, introduced back in 2024, keeps the automation out of the user's way but doesn't give you a place to put a real interface. And the most common workaround of all — build a Power App separately, then use UI automation to click into it — is exactly as fragile as it sounds. A selector changes, the app takes 400ms longer to load, and the flow is clicking on nothing.
What was missing wasn't a UI toolkit. It was a supported channel between two runtimes that were always meant to work together.
The run Power App action arrived in Power Automate for desktop build 2605, and it does three things: it can create, open and run a Power App that integrates directly with the desktop flow. The integration is the part that matters — the action establishes a native communication channel between the two experiences rather than just launching a URL.
That channel carries three kinds of traffic:
That third one is the genuinely new capability. Inputs and outputs replicate what you could already fake; event-driven subflow invocation lets you build a proper front end where the desktop automation becomes something the app calls, not the other way round.
Microsoft calls out guided forms, app front ends for desktop automations, and event-driven experiences. In practice, three shapes come up repeatedly.
The flow processes 400 invoices unattended and 12 fail a validation rule. Instead of writing those to a spreadsheet for someone to work through tomorrow, the attended run opens an app showing the invoice image beside the extracted fields, and the person fixes them in place. The outputs go straight back into the flow.
Fuzzy matching against a customer master returns three candidates. A dialog box can only list them as text. An app can show the address, the recent order history and a confidence score, which changes the decision quality — not just the aesthetics.
The desktop flow is the only way to write to an ancient thick client. The app becomes the interface staff actually use, and the automation becomes a service it calls. This is the inversion that the callable-subflow support unlocks, and it's the one worth designing around.
| Situation | Reach for |
|---|---|
| One yes/no confirmation, no context needed | Display input dialog, or the Confirm function if you're already in an app |
| Two to four simple typed values | Input dialogs — the migration cost isn't worth it |
| The person needs to see a document, image or record to decide | Run Power App |
| Decision depends on data from a second system | Run Power App, with the lookup as a callable subflow |
| The automation should run without blocking the user's screen | Picture-in-Picture run mode, unchanged |
| No human involved at any point | Unattended run — don't add an app to a flow that doesn't need one |
This is a preview feature, which carries the usual caveats and a few specific ones.
Pick one attended flow with a dialog chain longer than three steps. Rebuild only the interactive middle — leave the reading and writing exactly as they are — and follow this order:
The full action reference lives in the Power Platform actions documentation, and the announcement is in the June 2026 feature update.
Discussion
Comments