Workflows with Power Automate

Analogy categoryAnalogies

From SharePoint Designer to Power Automate

SharePoint Designer 2013 workflows are deprecated, and Power Automate is Microsoft's supported replacement for automating SharePoint business processes. Instead of a desktop designer tied to one site, Power Automate flows live in the cloud, are built with a visual, connector-based editor, and can reach far beyond SharePoint into Teams, Outlook, and hundreds of other services.

🏏

Cricket analogy: Retiring SharePoint Designer workflows for Power Automate is like a franchise retiring hand-written scorebooks in favor of a connected digital scoring system that updates every dashboard instantly.

Triggers and Actions

An automated cloud flow starts on a SharePoint event like 'When an item is created' or 'When an item is created or modified', firing without any user action. An instant flow, by contrast, is manually invoked — for example, 'For a selected item' attached to a list command bar button, giving users on-demand control over when the automation runs.

🏏

Cricket analogy: An automated flow triggered 'When an item is created' is like a stadium's PA system automatically announcing a boundary the instant it's scored, without anyone pressing a button.

Approval Flows

The Approvals connector's 'Start and wait for an approval' action pauses a flow's execution until a designated approver responds, via email, the Teams Approvals app, or the mobile Power Automate app. Patterns include a single approver, everyone must approve, or first-to-respond, and the flow's subsequent branch reads the approval outcome to update the SharePoint item accordingly.

🏏

Cricket analogy: A 'Start and wait for an approval' step pausing until a manager responds is like the third umpire holding play while reviewing a run-out on the big screen — the match pauses until the decision comes back.

json

// Example expression used in a Condition action
if(
  equals(triggerOutputs()?['body/Status/Value'], 'Pending'),
  'Escalate to manager',
  'No action needed'
)

// HTTP action calling an external API from within a flow
{
  "method": "POST",
  "uri": "https://api.example.com/notify",
  "headers": { "Content-Type": "application/json" },
  "body": {
    "listItemId": "@{triggerOutputs()?['body/ID']}",
    "title": "@{triggerOutputs()?['body/Title']}"
  }
}

Handling Errors and Throttling

Each action's 'Configure run after' setting defines what happens if the preceding action fails, times out, or is skipped, letting a flow branch into explicit error-handling logic rather than stopping silently. Concurrency control on the trigger caps how many instances of a flow can run in parallel, which matters when multiple runs might write back to the same list item and risk race conditions.

🏏

Cricket analogy: Configuring a 'run after has failed' branch is like a team's rain-delay contingency plan — a specific sequence of actions that only kicks in if the main play (the primary action) doesn't go as planned.

By default, a Power Automate flow triggered on a SharePoint list allows up to 25 concurrent runs; this can be adjusted via the trigger's 'Concurrency Control' setting (up to 50, or set to 1 to force strictly sequential processing), which matters when a flow writes back to the same list and race conditions between overlapping runs could corrupt data.

A classic beginner mistake is building a flow triggered on 'When an item is created or modified' that then updates a column on that same item — every update re-triggers the flow, creating an infinite loop that Power Automate will eventually detect and throttle, but not before burning through the tenant's daily API request allocation. Guard against this with a condition that checks whether the relevant column already has the target value before writing.

Power Automate is Microsoft's modern replacement for SharePoint Designer 2013 workflows, which are deprecated.
Cloud flows can be automated (triggered by list/library events) or instant (triggered manually, e.g., from a button or selected item).
'Start and wait for an approval' pauses flow execution until an approver responds via email, Teams, or the Approvals app.
'Run after' configuration on an action defines failure-handling branches distinct from the happy path.
Concurrency control determines how many instances of a flow can run in parallel against the same trigger.
Flows that update the same item they're triggered on risk infinite loops unless guarded with a condition.
Flow actions should implement retry policies for transient failures like network timeouts or throttling.