Power Automate flow design patterns

Power Automate flows are easy to build and surprisingly easy to ruin. Bad flows fail silently, generate alert fatigue, exceed API limits, and leave admin teams chasing ghosts. The good news: a handful of design patterns prevent almost all of it. This covers cloud flows specifically; desktop flows automating legacy UIs have their own failure modes, covered in Power Automate Desktop RPA errors.

Pick the right trigger.

• Instant triggers — manually invoked or button-triggered. For ad-hoc work.
• Automated triggers — when a Dataverse, SharePoint, or SaaS event happens. Default for most CRM automation.
• Scheduled triggers — on a clock. For periodic ETL, reminders, cleanup.

Don't poll on a schedule if an automated trigger exists — you'll generate noise and miss events.

Filter at the trigger, not in the flow

Most triggers accept filters. Filtering "Account created" by the Type = 'Customer' at the trigger saves the flow from spinning up on every Account create.

Idempotency

Flows can fire twice — connector retries, replays, manual re-runs. Design actions to be idempotent: check before inserting, use upsert semantics, store a correlation ID on the source record so retries don't double-process.

Concurrency control

A flow with many concurrent runs racing on the same record causes locks and corruption. Set concurrency limits to serialise runs per record key when ordering matters.

Error handling

Wrap critical actions in try/catch/finally scopes. Configure each action's retry policy (exponential backoff by default; sometimes None for non-idempotent calls). On error, log to a Dataverse log table and notify a Teams channel — don't email an individual.

Child flows

Pull repeated logic into child flows so it's one definition called from many parents. Saves duplication and isolates failure handling. One of the most common child-flow candidates is the approval step itself — Power Automate approvals, in depth covers the built-in Approvals connector and the patterns for multi-stage or delegated sign-off.

Variables and expressions

Keep flows readable: name variables, comment with the description field on each action, avoid 20-deep nested expressions. If an expression goes over one line, extract it into a Compose action with a descriptive name.

Performance

Use the OData $filter and $select on Dataverse list actions — the Filter rows and Select query fields are not cosmetic, they push work to the server.

Don't put long-running work in flows

Flows have action timeouts and run-duration limits. For work that takes more than a few minutes, hand off to Azure Durable Functions, Service Bus, or a Job Queue entry on the back-office system.

Test in dev, deploy with solutions

Build flows inside a managed solution so they version, export, and import cleanly across environments. Building directly in production is the express route to drift.

Monitor

The Power Platform admin centre shows flow run history, success rate, and quota usage. Check it weekly until your flows are boring.

Where to go next

The companion guides are error handling patterns, child flows, and connectors for Dynamics 365. When a flow fails anyway, flow failures explained decodes the message. And before a high-volume flow is built, plug-ins vs Power Automate is the decision to make. Before designing any flow at all, process mining can tell you whether the process you're about to automate is actually the one that runs in practice.