Cloud Flows: Triggers, Connectors and Actions
Choosing the right trigger for a scenario, evaluating connectors, and configuring actions — including the Dataverse trigger's scope and filter settings that quietly decide whether a flow fires.
Domain 3 starts here, and it is the big one
Domain 3 is 40–45% of the exam — roughly as much as the other two combined. It opens with cloud flows, which are the workhorse of business logic in Power Platform.
The objective wording is worth noticing: “Recommend cloud flow triggers” and “Evaluate and recommend connectors.” Again, these are judgement skills. Questions will hand you a scenario and ask which trigger fits.
Choosing a trigger
Every flow begins with exactly one trigger, and the trigger decides everything downstream — when the flow runs, what data it starts with, and whether it can run at all.
A cloud flow is a recipe that runs itself. The trigger is what starts it — a doorbell ringing, someone pressing a button, or an alarm clock going off. The actions are the steps it follows afterwards, and connectors are the plugs it uses to reach other apps.
| Trigger family | Fires when | Scenario language that points here |
|---|---|---|
| Automated | An event happens in a connected service — a row changes, a file arrives, an email is received | 'Whenever a run is marked delayed…' |
| Instant (manual) | A person deliberately starts it — from an app, a button, or the Power Automate app | 'The dispatcher should be able to trigger a re-route…' |
| Scheduled | A recurrence you define | 'Every night at 2 a.m.…' or 'every Monday…' |
The reasoning shortcut
Ask: what starts this?
- Something happened → automated.
- Somebody decided → instant.
- The clock → scheduled.
The most common wrong answer is a scheduled flow where an automated one belongs. If a scenario says “as soon as”, a nightly schedule is wrong — it introduces up to 24 hours of latency.
The reverse trap also exists: if a scenario needs to process records that have not changed — “flag runs that have been sitting unassigned for three days” — no change event will ever fire. That genuinely needs a schedule.
The Dataverse row trigger, in detail
The When a row is added, modified or deleted trigger is the one you will meet most often, and it has enough configurable detail to make good exam questions.
It requires three things: a change type, a table name, and a scope.
Change type
Defines which combination of changes runs the flow — Create, Update, or Delete.
A behaviour that surprises people
When multiple updates occur to a single row, Power Automate evaluates the trigger for each update — even if the updated values are the same as the previous ones. That can result in multiple flow runs.
So a flow that “runs too many times” is often not a bug. It is the trigger doing exactly what it is documented to do, in response to repeated updates that did not change anything meaningful.
Scope
Scope determines whose rows are watched. There are four values, and they map directly onto Dataverse’s ownership model.
| Scope | Rows monitored | Use when |
|---|---|---|
| User | Rows owned by you (the flow owner) | A personal automation |
| Business Unit | Rows owned by anyone in your business unit | The process is departmental |
| Parent: Child business unit | Rows owned by anyone in your business unit or a child business unit | The process spans a unit and everything beneath it |
| Organization | Actions taken by anyone within the environment | The process is genuinely enterprise-wide |
Scope is the number one cause of 'my flow didn't run'
The default scope is narrow. A maker builds and tests the flow — it works, because they are creating the test records themselves and therefore own them. Then it goes live, other people create records, and nothing happens.
The diagnosis: scope was left at User. The records are owned by someone else, so they were never monitored.
This is a realistic troubleshooting scenario and a very fair exam question. “It works for me but not for anyone else” plus a Dataverse trigger equals scope.
Filters
Two filter mechanisms narrow when the flow fires, and both have traps worth knowing.
Select columns — three documented gotchas
Select columns takes a comma-separated list of column names, so the flow only runs when those columns are part of an update.
- It applies to the Update condition only. Create and Delete apply to all columns of a row.
- Lookup columns are not supported. If you specify a lookup column, changes to it will not trigger the flow. Use scalar types — text, number, date/time, choice.
- The flow triggers when a listed column is included in the update, regardless of whether the data actually changed. So do not include columns that are always present on update — such as the primary key — because that causes every update to trigger the flow.
It is also not supported on virtual tables.
Filter expression is the more precise instrument: an OData-style expression such as firstname eq 'John' or contains(firstname,'John'). The flow runs only when the expression evaluates to true after the change is saved in Dataverse.
One more documented limitation
The When a row is added, modified or deleted trigger does not support triggering flows on relationships of type 1:N or N:N.
So “run a flow when a Depot Run is associated with a Driver” is not something this trigger handles through the relationship itself.
Evaluating connectors
A connector is how a flow reaches a service. The exam objective is “evaluate and recommend connectors,” so the skill is choosing, not configuring endpoints.
What to weigh when recommending a connector
- Standard or premium? Premium connectors require appropriate licensing. Recommending one has a cost implication, and scenarios sometimes hint at licensing constraints.
- Does a first-party connector already exist? Reaching for a generic HTTP action when a purpose-built connector exists is a poor recommendation — you lose triggers, typed outputs and maintained authentication.
- Data loss prevention. DLP policies group connectors into business and non-business categories, and a flow cannot mix across the boundary. A perfectly good technical design can be blocked by policy — and that is Mei’s domain.
- Authentication model. Connections run as an identity. Whose? A flow that works for its owner and fails for everyone else is often a connection-identity problem.
Custom connectors are a boundary
AB-410 asks you to evaluate and recommend connectors. Authoring a custom connector — defining the OpenAPI definition, actions and authentication — is PL-400.
So “recommend a custom connector for this unsupported API” can be a correct AB-410 answer. “Write the OpenAPI definition” will not be.
Configuring actions
Actions are the steps after the trigger. A few configuration ideas recur in exam scenarios:
| Setting | What it does | Reach for it when |
|---|---|---|
| Concurrency control (on the trigger) | Limits how many runs of the flow execute in parallel — configured in the trigger's settings, not on an action | Order matters, or a downstream system cannot handle parallel load |
| Retry policy | Controls whether and how a failed action is retried | The downstream service is occasionally flaky and a retry would genuinely succeed |
| Configure run after | Runs an action based on the previous one's outcome — succeeded, failed, skipped, timed out | You need a genuine catch branch |
| Scope | Groups actions so their combined outcome can be evaluated | Building a try/catch pattern |
Where each concurrency setting actually lives
This trips people up because the word appears in two places and they control different things.
- Flow-run concurrency is a trigger setting. It caps how many runs of the whole flow happen at once, and switching it on is what forces runs to queue rather than overlap.
- Apply to each concurrency is a setting on the loop, controlling how many iterations run in parallel inside a single run.
Retry policy and Configure run after are genuine action settings. If a question asks where you would stop two runs of the same flow colliding, the answer sits on the trigger.
Kite Freight
Ravi wants dispatch notified as soon as a run is marked delayed.
| Question | Nadia’s answer |
|---|---|
| What starts it? | A row change — the Depot Run status becoming Delayed. Automated trigger |
| Which trigger? | When a row is added, modified or deleted, change type Update, table Depot Run |
| Scope? | Organization — drivers across the whole business update runs, not just Nadia |
| Narrow it further? | Use Select columns for the status column and a Filter rows expression for the Delayed value |
| Why both? | They do different jobs. Select columns stops the flow firing on updates that do not touch status at all. Filter rows is evaluated after the change is saved, so on its own it stays true for every later edit to a row that is already Delayed. Neither one proves a genuine transition, so keep explicit transition or idempotency logic downstream |
Two weeks later the flow is firing several times per delayed run. The cause is not a bug: drivers are saving the record repeatedly, and Power Automate evaluates the trigger for each update. Nadia adds a condition so downstream actions only run on a genuine transition into Delayed.
Quick recall
Check yourself
Kite Freight needs a flow that identifies Depot Runs which have been sitting unassigned for more than three days and escalates them. Which trigger type is appropriate?
A maker sets the Dataverse trigger's Select columns to include the status column and the record's primary key. The flow now runs on every single update to the table. Why?
A business process must reach an internal API that has no first-party connector. On AB-410, what is the appropriate response?