Power Automate Cloud Flows & Approvals, End to End

I've written a lot about Power Automate from SharePoint's side — triggers, loops, the "Send an HTTP request" action. This piece zooms out to the flow itself and the one scenario every organisation asks for first: approvals. The built-in Approvals connector makes a request-and-wait workflow almost trivial to start — and surprisingly easy to get subtly wrong. Let's build one properly.

Three kinds of cloud flow

Before the canvas, know which trigger you need. A cloud flow is defined by how it starts:

• Automated — fires on an event ("When an item is created" in SharePoint, "When a new email arrives").
• Instant — a person triggers it on demand (a button, a "For a selected item" action in a list).
• Scheduled — runs on a recurrence (every night at 02:00).

An approval flow is usually automated — a new request appears, and the flow routes it for sign-off.

The shape of an approval flow

At its core the pattern is: trigger → start the approval and wait → branch on the outcome → act. Here is the flow we'll build, as it appears in the designer:

The approval pattern: trigger, a blocking approval, then a condition that branches on the returned Outcome.

"Start and wait for an approval"

The Approvals connector offers two flavours. Create an approval + Wait for an approval are separate actions for advanced choreography; for 95% of cases use the combined Start and wait for an approval, which posts the request and pauses the run until someone responds. Configure the approval type:

Approval type	Behaviour
Approve/Reject — First to respond	Any one assignee's response decides it.
Approve/Reject — Everyone must approve	All assignees must approve; one rejection fails it.
Custom Responses — Wait for one / for all	Your own response options instead of Approve/Reject.

Branching on the outcome

After the approval completes, a Condition checks the result. The trap: the Outcome value is the literal string Approve (not "Approved", not localized) for the standard Approve/Reject type. Compare exactly:

// Condition (advanced mode expression)
@equals(outputs('Start_and_wait_for_an_approval')?['body/outcome'], 'Approve')

In the If yes branch, update the source item and notify the requester; in If no, send the rejection with the approver's comment pulled from the responses:

// Grab the first responder's comment for the rejection email
@first(outputs('Start_and_wait_for_an_approval')?['body/responses'])?['comments']

Expressions you'll actually use

Power Automate's expression language (Workflow Definition Language) is where flows graduate from clicking to engineering. A few that earn their keep:

// Format a due date 3 business-ish days out
addDays(utcNow(), 3, 'yyyy-MM-dd')

// Safe access to a possibly-missing property (no run failure)
coalesce(triggerOutputs()?['body/ContractValue'], 0)

// Build the approval title from trigger data
concat('Approve contract: ', triggerOutputs()?['body/Title'])

Make it resilient: scopes and "Configure run after"

A real approval flow shouldn't die silently when the "Update item" step hits a transient error. Wrap the work in a Scope named Try, add a second Catch scope, and use Configure run after on the Catch so it runs only when the Try has failed, is skipped, or times out:

Try / Catch: "Configure run after" turns Power Automate's default fail-fast behaviour into deliberate error handling.

Inside Catch, post to a Teams channel or log to a SharePoint "Flow errors" list with result('Try') so failures are visible, not invisible.

The takeaway

An approval flow is four moves: trigger, Start and wait for an approval, branch on the exact Outcome string, and act — wrapped in a Try/Catch so it fails loudly. The Approvals connector hands you Teams and Outlook integration for free, which is precisely the kind of leverage that makes Power Automate worth reaching for before you write a single line of code. The judgment — picking the right approval type, comparing the outcome exactly, handling errors — is still yours.