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.

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.

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.