What it does

An app can start a cloud flow with a Power Apps trigger by calling FlowName.Run( arguments ) from any behaviour property. The flow keeps running even if the app is closed, and if it ends with a response action it hands values back to the app.

Key facts

• The Power Automate pane in Studio is the current experience and is enabled by default. The classic experience is retired and Microsoft says it should only be used for troubleshooting.
• With the pane enabled, adding a flow preserves the existing formula on the property. With it disabled, adding a flow wipes whatever formula was there — which is why the old guidance was to copy your formula out first.
• To add an existing flow you need access to it, access to see flows in the same solution, and the flow must have a Power Apps trigger.
• Change a flow outside Power Apps Studio and you must use Refresh on it in the pane. Skipping this can make the flow fail even in already-published apps, and causes the app to keep validating connections against stale information on every run.
• Return values come from a response action at the end of the flow. Capture the result with Set or UpdateContext so multiple returned properties can be read in different places.
• The flow runs as the calling user's permissions for anything they trigger. A user without rights to what the flow does will simply see it fail.
• Arguments passed from Power Apps to Power Automate travel as network traffic and can be intercepted or altered. Microsoft's explicit guidance is to validate parameter values inside the flow rather than trusting the app.
• Removing a flow from an app removes only the reference. The flow stays in the environment and can be re-added or used elsewhere.
• Flows in a solution use connection references, so they participate in ALM properly. Flows created outside one don't until they're converted.

When to use / skip

Call a flow when the work is genuinely asynchronous, genuinely long-running, or needs a connector the app shouldn't hold — sending mail, generating a document, hitting a third-party API, orchestrating approvals. Don't call a flow for a Dataverse read or write; Power Fx can invoke Dataverse actions directly now, it's faster, and Studio will tell you so with a banner. The pattern to avoid entirely is the flow-as-a-workaround, where a flow exists only to dodge a delegation warning. That trades a visible warning for an invisible latency spike and an extra licensing surface.

Configuration decisions

• Whether the app waits on the flow's response or fires it and moves on, because the user is watching either way.
• What the input contract is and how strictly it's versioned, since changing it breaks every caller.
• Which parameters the flow validates rather than trusts, given they're alterable in transit.
• Whether the flow lives in the same solution as the app, which decides whether it deploys cleanly or has to be reconnected by hand.
• How failure surfaces: a return value the app inspects, or an unhandled error the app has to catch with IfError.

Gotchas

• Editing a flow in the Power Automate portal and not refreshing it in the app is the most common cause of "it worked yesterday". The published app breaks even though nobody touched it.
• With the Power Automate pane disabled, adding a flow to a button silently clears a complex OnSelect formula. It's recoverable only if someone copied it first.
• The user runs the flow with their own permissions, so an app that works perfectly for the maker fails for half the pilot group. That's a permissions problem presenting as an app bug.
• Every flow call is a round trip plus flow startup time. A user-facing button that calls a flow feels slow in a way that a Power Fx call doesn't, and it compounds if the flow calls child flows.
• Passing sensitive values as arguments is a real exposure, not a theoretical one. An email address passed from the app can be swapped for someone else's if the flow doesn't check it.

Consultant notes

• Establish early which side owns which logic. A project where every button calls a flow ends up with business rules split across two products and two run histories, and nobody can answer a support question without checking both.
• Power Apps-triggered flows and their licensing sit inside the Power Platform licensing guide rather than in the product docs. Get the client's licensing position confirmed in writing rather than reasoning about it from feature pages.
• Put a correlation ID into every flow call and log it at both ends. Tracing a user's complaint across an app session and a flow run history is otherwise guesswork.
• Warn the client that flows called from apps make the app's availability depend on the flow's connections and their owners. It's the same "when the maker leaves" risk as connection references, one step removed and easier to miss.

---

Worth revisiting once the classic Power Automate experience is fully removed, or if direct Dataverse actions displace more of this pattern.