Power Automate patterns

7.1The Dataverse trigger

Change type, table, scope, and the two filters

A flow triggered from Dataverse runs after the operation that started it has committed (§6.5). What you still get to decide is how often it starts, and you decide that in the trigger's own settings rather than in the flow's first condition.

The When a row is added, modified or deleted trigger runs a flow whenever a row of a selected table and scope changes or is created, and it takes three required parameters: the trigger condition Change type, the Table name, and the Scope. Change type sets which combination of changes runs the flow, and triggerOutputs()['body/SdkMessage'] carries Create, Update or Delete accordingly. The trigger does not support triggering on relationships of type 1:N or N:N.citedsource: Power Automate docs — Trigger flows when a row is added, modified, or deleted — the required parameters

Scope names the rows that are watched, by ownership: User for rows owned by the flow's user, Business Unit for rows owned by anyone in their business unit, Parent: Child business unit for that business unit or a child of it, and Organization for actions taken by anyone within the environment.citedsource: Power Automate docs — Trigger flows when a row is added, modified, or deleted — the four scopes

Scope and the two filters below do different work, and confusing them is how you get a flow that runs constantly and exits on its first condition. Scope decides whose rows; the column filter decides which changes; the filter expression decides which resulting rows.

"triggers": {
  "When_an_account_row_is_modified": {
    "type": "OpenApiConnectionWebhook",
    "inputs": {
      "host": {
        "connectionName": "shared_commondataserviceforapps",
        "operationId": "SubscribeWebhookTrigger",
        "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
      },
      "parameters": {
        "subscriptionRequest/message": 3,
        "subscriptionRequest/entityname": "account",
        "subscriptionRequest/scope": 4,
        "subscriptionRequest/filteringattributes": "name,telephone1"
      },
      "authentication": "@parameters('$authentication')"
    },
    "conditions": [
      { "expression": "@not(equals(triggerOutputs()?['body/statecode'], 1))" }
    ]
  }
}

7.2Error handling as a discipline

The run-after setting, the scope as try and catch, and terminate

By default a cloud flow stops on a failed action and marks the run failed. You can choose something else, action by action, with the constructs below.

Run after settings specify what happens if an action fails, times out, is skipped, or is successful, and the conditions are set per action, which is how an alternative path is built. The documented example makes a flow send an email notification when a preceding Update a row action fails.citedsource: Power Automate docs — Employ robust error handling — Run after settings

A scope is a container that groups related actions, and when a scope runs the actions inside it execute as one block. Each scope reports a status — Succeeded, Failed, Skipped and others — and scopes work with run-after conditions to build try, catch and finally patterns. When a scope fails it reports a single Failed status for the whole scope, so identifying the action that failed means expanding it. Power Automate supports a maximum of eight nested levels of actions, counting scopes, conditions, switch cases and apply-to-each loops, and a flow deeper than that neither saves nor runs; triggers and response actions are to remain outside scopes.citedsource: Power Automate docs — Use scopes to organize actions in cloud flows — what a scope is and what it reports

The documented try/catch pattern puts the main actions in a Try scope and the error handling in a Catch scope configured to run if the Try scope fails, with the result() function filtered to get the error. The Terminate action stops the flow and sets a status, so that a critical error can end the run as Failed with a status and a message that say why.citedsource: Power Automate docs — Employ robust error handling — the try and catch pattern and Terminate

Three properties of that arrangement decide how it behaves in production. The catch scope runs on the try scope's aggregate status, so a failure anywhere inside the try reaches it. The failing action's identity is inside the scope rather than on it, so your catch has to read result() to find out what went wrong. And a run that ends through Terminate ends with the status you gave Terminate, which is what puts a handled failure into the run history as a failure rather than a success.

7.3Retry policies

What an action does before it is allowed to fail

Retries happen before run-after does. An action a policy retries is not a failed action until the policy is exhausted, which is why you configure the two in different places and read them in this order.

The default retry policy depends on the flow's performance profile. On the Low profile it sends up to two retries at exponentially increasing intervals, scaling by 5 minutes up to an interval of approximately 10 minutes for the last retry. On the Medium and High profiles it sends up to 12 retries at exponentially increasing intervals, scaling by seven seconds up to an interval of approximately 1 hour for the last retry.citedsource: Power Automate docs — Limits of automated, scheduled, and instant flows — the default retry policy

Where the default is replaced, the settings are bounded at 90 retry attempts, a retry maximum delay of one day, and a retry minimum delay of five seconds.citedsource: Power Automate docs — Limits of automated, scheduled, and instant flows — the retry setting bounds

A retry policy is aimed at transient failures caused by temporary or intermittent problems with a network or service, and retries at either fixed or exponential intervals. Exponential policies are preferred because they extend the retry period over time and increase the chances of the action completing, avoiding overwhelming the system with frequent retries.citedsource: Power Automate docs — Employ robust error handling — why exponential is preferred

A retry policy on an action that fails deterministically multiplies what the failure costs you and changes nothing about the outcome. A malformed payload is still malformed on the last attempt, and what the run consumes is the attempts rather than the work.experientialbasis: flows retrying a call that returned a deterministic validation error, where the policy turned one rejected payload into a run's worth of identical rejections

7.4Concurrency and ordering

How many runs at once, and what that costs in sequence

A Dataverse-triggered flow is invoked per event, and the platform will not sequence the invocations for a given row unless you tell it to.

When multiple updates occur to a single row, Power Automate evaluates the trigger for each update, even where the updated values are the same as the previous ones, and those updates can result in multiple flow runs.citedsource: Power Automate docs — Trigger flows when a row is added, modified, or deleted — multiple updates to one row

Concurrent runs are unlimited while Concurrency Control is off, and are bounded between 1 and 100 with a default of 25 when it is on. Concurrency Control is a trigger setting, off by default, and turning it on cannot be undone without deleting and re-adding the trigger. With it on, the number of runs that can be queued at the maximum is 10 plus the degree of parallelism, and triggers arriving beyond that might be retried by the connector, with those retries perhaps not succeeding while the waiting limit continues to be met — so the documentation's own advice for making every trigger produce a run is to leave the setting off.citedsource: Power Automate docs — Limits of automated, scheduled, and instant flows — trigger concurrency control

Inside a run, an apply-to-each loop defaults to a concurrency of 1 and takes a value between 1 and 50, and processes at most 5,000 array items on the Low performance profile or 100,000 on the others. Split-on debatching takes the same two ceilings without trigger concurrency, and drops to 100 items with it.citedsource: Power Automate docs — Limits of automated, scheduled, and instant flows — loop and debatching concurrency

So turning concurrency control on buys you bounded parallelism and charges twice: a queue that can drop triggers, and a trigger you have to delete and re-add to undo the setting.

Ordering is something teams assume and rarely write down. Two runs triggered by two edits a second apart can finish in either order, and where both write the same column the value that survives is the one written by whichever run finished last — not necessarily the one that read the later data.experientialbasis: flows that wrote a derived value on every edit of a row, where two runs for two quick edits committed in the order they finished rather than the order they started

7.5Service protection limits and the plan's own

Two ceilings, measured differently, reached by different things

Two separate systems bound your throughput, and the platform evaluates them separately. Dataverse's service protection limits are about how hard one user is pressing the API; Power Automate's request limits are about what a licence entitles a flow to run.

Listing all environments from your tenant...

Listing environment groups from your tenant...
Active Environment           Group Environment ID                       Environment Url                       Type      Organization ID
*      skydude's Environment -     3caaae88-df92-e1ea-9467-7ce90a51b602 https://org85700aeb.crm.dynamics.com/ Developer c5fa366c-5190-f111-b8cf-6045bd056918

The other two environments this guide uses are in the same listing and are elided here.

7.6Child flows and their contract

What a callable flow owes its caller, and what the platform asks of both

A child flow is the platform's answer to a flow that has outgrown one screen, and to logic you want in more than one place. The arrangement carries requirements that are easy to meet while you are authoring and awkward to retrofit.

Both flows live in a solution, and the documentation's guidance is to create the parent and all child flows directly in the same one, because importing a flow into a solution can give unexpected results. The child flow uses the Manually trigger a flow trigger with inputs defined on it, and returns data through Respond to a Power App or flow or the HTTP Response action. The parent calls it with the built-in Run a Child Flow action, and only flows the caller can access and that sit in a solution are offered.citedsource: Power Automate docs — Create child flows — the requirements on both flows

A child flow using anything beyond built-in actions and the Microsoft Dataverse connector has its connections set to Use this connection rather than Provided by run-only user, because connections cannot be passed from parent to child and child flows support embedded connections alone; without that the platform refuses the flow as a child workflow. While the child runs the parent waits — for one year where the child uses built-in connections and Dataverse, and 30 days otherwise. On export and import into another environment the parent and child are relinked automatically, with no URL to update.citedsource: Power Automate docs — Create child flows — connections and the waiting parent

Child flows are Microsoft's own answer to the 500-action ceiling and to the eight-level nesting ceiling, named in the notes on both.citedsource: Power Automate docs — Limits of automated, scheduled, and instant flows — child flows as a decomposition

The part of that contract that decays is the input list. A child flow's inputs are a signature with no type checking beyond the primitive kinds and no compiler to tell you when a caller stops matching it, and the failure surfaces inside the child as a null where a value was expected.experientialbasis: decompositions where a child flow's inputs were widened over several releases until each caller passed a payload shaped for itself

7.7Solution-aware flows at deploy time

What an import does to a flow, and what it leaves for a person

A solution-aware flow is a workflow row of category Modern Flow, carried between environments like any other component (§3.6). What the import does to it is where your deployment stops being automatic.

<Workflow WorkflowId="{c6701a01-6701-6701-9c67-c67c67c67c67}" Name="ch67DailyNote">
  <JsonFileName>/Workflows/ch67DailyNote-C6701A01-6701-6701-9C67-C67C67C67C67.json</JsonFileName>
  <Type>1</Type>
  <Category>5</Category>
  <Mode>0</Mode>
  <Scope>4</Scope>
  <StateCode>1</StateCode>
  <StatusCode>2</StatusCode>
  <IntroducedVersion>1.0</IntroducedVersion>
  <PrimaryEntity>none</PrimaryEntity>
</Workflow>

The sidecar carries further elements — Subprocess, OnDemand, TriggerOnCreate,
TriggerOnDelete, AsyncAutoDelete, SyncWorkflowLogOnFailure, RunAs, IsTransacted,
IsCustomizable, BusinessProcessType, IsCustomProcessingStepAllowedForOtherPublishers
and LocalizedNames — all of them elided here and present in artifacts-ch07.md.

Connected as skydude@itrancyngergmail.onmicrosoft.com
Connected to... skydude's Environment

Solution Importing...

Solution Imported successfully.

Publishing All Customizations...

Published All Customizations.

The read on either side of this run is in artifacts-ch07.md. Both reads return
the same two rows, both Draft.