3.3 Invoking Power Automate Cloud Flows from a Canvas App

Canvas Apps Call Flows as Functions

A Power Automate cloud flow can be added to a canvas app from the Power Automate pane in Studio (Insert or Data > Power Automate), and once added, behaves like a callable function: the flow's name becomes available in the formula bar, and invoking it — MyFlow.Run(param1, param2) — starts a run of the flow from the app's perspective. This is the mechanism the blueprint calls "use Power Automate cloud flows to implement business logic from a canvas app" (3c): instead of stretching Power Fx to do something it's poorly suited for (complex branching business rules, calls to systems without a first-class connector, heavier orchestration), the developer delegates that logic to a flow and treats it as a reusable service.

The Power Apps Trigger and Parameters

A flow becomes callable from a canvas app only when it starts with the Power Apps (V2) trigger — an instant cloud flow trigger purpose-built for this scenario. Inside the trigger, the flow author adds typed inputs (Text, Number, Boolean, File, Email) that surface as ordered parameters in the app's Run() call, matched positionally, not by name. Because parameters are positional, reordering or removing a trigger input after an app has already wired up the call breaks the calling formula — a common ALM gotcha the exam expects developers to anticipate and manage through careful trigger design and testing before republishing a flow other apps depend on.

Returning Values With Respond to a PowerApp or Flow

By default, a flow runs without handing anything structured back to the caller. To return data, the flow must include a Respond to a PowerApp or flow action, which defines named output values (Text, Number, Boolean, File) the app can read once the run completes. In the canvas app, the result of MyFlow.Run(...) is a record whose fields match those Respond outputs, so a formula like:

Set(varResult, MyFlow.Run(varAccountId));
Notify(varResult.statusmessage, NotificationType.Success)

captures the flow's structured result and drives UI feedback. Without a Respond action, Run() still completes, but there is nothing meaningful in the returned record for the app to consume.

Synchronous Waiting vs. Fire-and-Forget

Because a canvas app formula thread blocks while awaiting a flow's response, developers wrap long-running or non-essential calls in patterns that don't stall the UI — showing a loading spinner control gated on a variable set before the call and cleared after, or deliberately not awaiting the result at all when the app doesn't need it. Flows called synchronously from canvas apps are also subject to timeout behavior, so logic that may run long (bulk processing, multiple downstream API calls) is generally better suited to an asynchronous, event-triggered flow than one an end user is actively waiting on inside the app UI.

Choosing the App vs. the Flow for Business Logic

The blueprint's technical-design domain already asks where business logic should live; this section is the canvas-specific instance of that decision. Push logic into a flow rather than Power Fx when:

• The logic needs a connector or system Power Fx can't reach directly, or needs elevated or service-account credentials that shouldn't be embedded in a canvas app's client-evaluated formulas.
• The same logic must be reused outside this one app — a flow can be triggered by this canvas app, a different app, a schedule, or an event, while a Power Fx formula embedded in one app's control is not reusable outside that app.
• The operation is a multi-step orchestration (create a record, then call an external API, then send an email, then update a status) that would be unreadable as a single nested Power Fx expression.
• Auditing or approval steps are required — flows have built-in run history, retry, and approval actions that Power Fx has no equivalent for.

Conversely, keep logic in Power Fx when it's purely presentational, needs to run instantly on every keystroke or selection (a flow call always incurs network latency a local formula doesn't), or doesn't need to be shared beyond the current screen.

Packaging and Testing the Connection

Because a flow added to a canvas app becomes a dependency the app references by name, both the flow and the app are typically shipped together inside the same solution so ALM tooling tracks the relationship and moves both components through environments as a unit. Testing this integration deserves its own attention: a developer should validate the flow independently (using Power Automate's own test/run history) before wiring it into the app, then validate the end-to-end call from the app itself, since a flow that works when triggered manually can still fail when called from Run() if a required input isn't supplied or a connection reference isn't configured in the target environment. Because canvas apps evaluate the flow call the same way they evaluate any other formula, a broken or disabled flow shows up as a runtime error at the call site, which Monitor (covered later in this chapter) is the right tool to diagnose.