8.3 Automating Business Processes from Canvas Apps

Canvas apps rarely stand alone. AB-410 expects you to trigger cloud flows from Power Fx, pass data in, get results back, and know which automation tool fits which requirement.

Calling a Cloud Flow from Power Fx

In Power Apps Studio, open the Power Automate pane on the left rail and either create a new flow or add an existing one. Flows created here start with the Power Apps trigger (V2) — the current version, and the one the exam means when it says Power Apps trigger. The V2 trigger is a major improvement over V1: you declare typed inputs (text, number, boolean, email, file, and more) directly on the trigger, and each input becomes a parameter of the flow's .Run() method.

After the flow is added to the app, call it from any Power Fx formula:

Set(varResult, SendApproval.Run(txtTitle.Text, varUser.Email))

Parameter order and count must match the trigger's declared inputs exactly. If you later add inputs to the trigger in Power Automate, use the pane's refresh option in Studio so the app sees the new signature — and update every .Run() call accordingly.

Getting Results Back

To return data to the app, end the flow with the Respond to a PowerApp or flow action, which defines typed outputs (text, number, yes/no, file). In the app, the outputs hang off the value returned by .Run():

Set(varResult, CheckCredit.Run(varAccountId)) — then read varResult.status in a label.

Keep response flows fast: the app waits synchronously for the response. Long-running work (nightly cleanups, multi-day approvals) should be fire-and-forget — the app calls .Run() without needing an answer, and the flow notifies users through email or Teams instead. If a flow is expected to respond but a branch skips the Respond action, the app simply waits and then errors, so design every path of a response flow to end at the Respond action.

Naming and Maintenance

• Rename the flow before adding it to the app — the flow's name becomes the Power Fx function name.
• Removing a flow from the app breaks every .Run() call that referenced it.
• Flows used by apps should live in solutions with connection references for healthy ALM.

Two exam-relevant footnotes on permissions: a flow triggered from an app runs with the app user's connections, and when you share the app, the flows connected to it are shared along with it. And if the flow uses premium connectors, every app user needs licensing that covers premium usage — the app sharing dialog flags this.

Buttons vs. Events: Where to Put the Flow Call

• OnSelect of a button — the workhorse: an explicit user action such as Submit for approval.
• OnSuccess of an edit form — runs only after SubmitForm succeeds; the freshly saved record is available as Form1.LastSubmit, so NotifyManager.Run(Form1.LastSubmit.ID) is the standard save-then-automate pattern.
• OnVisible of a screen — load-time automation, used sparingly.
• Avoid OnChange for flow calls; it fires per keystroke or per selection and can flood the flow with runs.

Two subtleties behind that pattern: for a new record, the ID is assigned by Dataverse during the save, so it simply does not exist in OnSelect before SubmitForm runs — OnSuccess is the only hook guaranteed to have it. And gate the submit button with If(Form1.Valid, SubmitForm(Form1)) so downstream automation never fires on data the form itself considers invalid.

Power Fx vs. Cloud Flow vs. Business Rule

The classic exam trap: a rule like "reject discounts above 20%" implemented only in Power Fx can be bypassed by a model-driven app, an Excel import, or an API call. When the rule must always hold, push it to the data layer with a business rule; keep Power Fx for the user experience.

Calling an Agent from a Canvas App (Awareness Level)

As an Intelligent Applications Builder exam, AB-410 also expects awareness that a canvas app can invoke a Microsoft Copilot Studio agent. The common pattern is to call a cloud flow that routes the user's prompt to the agent and returns the generated answer through the Respond action, which the app then displays. Know that the pattern exists and where it fits; deep agent configuration is covered elsewhere in this guide.

Error Handling on Flow Calls

A .Run() call can fail: the flow is turned off, a connector is throttled, or the Respond action never executes. Wrap calls defensively:

IfError(SendApproval.Run(varId), Notify("Automation failed: " & FirstError.Message, NotificationType.Error))

Enable Formula-level error management and handle App.OnError for otherwise unhandled failures. Deep error-handling patterns — retries, logging, and troubleshooting failed runs — are covered in section 9.3.