11.1 Recommending Cloud Flow Triggers

Every cloud flow begins with exactly one trigger. The trigger decides when the flow runs, what data arrives in the trigger payload, and sometimes which license the maker needs. AB-410 loves to test trigger selection: a scenario describes a business event, and you must recommend the trigger that fits with the fewest moving parts.

The Three Trigger Families

Cloud flow triggers fall into three families:

• Automated triggers fire when an event happens in a connected service — a Dataverse row changes, a SharePoint item is created, an email arrives, a Microsoft Forms response is submitted.
• Instant (manual) triggers fire when a person deliberately starts the flow — a button in the Power Automate mobile app, a call from a canvas app, a selected message in Teams.
• Scheduled triggers fire on a timetable you define with the Recurrence trigger — interval plus frequency (Second, Minute, Hour, Day, Week, Month), with optional start time, time zone, and 'at these hours/minutes' precision.

Automated Triggers: Dataverse and SharePoint

The most exam-relevant automated trigger is the Microsoft Dataverse trigger When a row is added, modified or deleted. Its parameters are where the exam hides its traps:

• Change type — Added, Modified, Deleted, or Added or Modified. Choosing narrowly is the first optimization.
• Table name — the Dataverse table to watch, such as Accounts or a custom Expense Report table.
• Scope — which rows the trigger can see: Organization, Business unit, Parent: Child business unit, or User. Scope controls whose rows fire the trigger, not who runs the flow.
• Select columns — a comma-separated list of columns ('filtering attributes'). For the Modified change type, the flow fires only when one of these columns is actually updated. Leave it blank and any column change fires the flow.
• Filter rows — an OData filter such as statuscode eq 1 that the row must satisfy.

Exam trap: Select columns only narrows Modified events; an Added event always fires regardless of Select columns, because a brand-new row counts as every column having changed.

The SharePoint trigger When an item is created (and its sibling When an item is created or modified) works against a Site Address and List Name. It is a polling trigger: Power Automate checks the list on an interval and starts a run for each new item found. The Dataverse trigger is effectively webhook-style — Dataverse pushes a callback and the flow starts within seconds. Know the difference: polling triggers introduce a small, plan-dependent delay; webhook triggers are near real-time.

Instant Triggers: Button and Power Apps (V2)

Manually trigger a flow is the classic button trigger. You can define typed inputs — text, yes/no, file, date, number, email — that the runner fills in when they start it. Button flows can be shared with run-only users, who execute the flow using either their own connections or the owner's connections, depending on how each connection in the flow is configured.

The Power Apps (V2) trigger is how a canvas app starts a flow. It replaced the older Power Apps trigger and lets you declare named, typed inputs directly in the designer; in Power Apps Studio you call it as FlowName.Run(input1, input2). Always recommend V2 for new canvas apps — the V1 pattern of editing the flow breaks the app's formula signature whenever inputs change.

Scheduled Triggers: Recurrence

The Recurrence trigger runs the flow on a schedule: every 5 minutes, every weekday at 07:30, the first Monday of the month. Use the Time zone and Start time properties to pin it to a wall clock, and the advanced At these hours / At these minutes fields for patterns like 'weekdays only'. Scheduled triggers are the right answer for batch scenarios: a nightly Dataverse-to-SQL sync, a Monday-morning status digest, a monthly archive job. If the scenario says 'every night', 'each Monday', or 'once an hour', think Recurrence — not an automated trigger.

Trigger Conditions: Stop Runs Before They Start

A trigger condition is a Workflow Definition Language expression added in the trigger's Settings (Settings → Trigger conditions → Add). Every condition must evaluate to true before a run is created. Example for a Dataverse trigger that should fire only for won opportunities:

@equals(triggerOutputs()?['body/statuscode'], 2)

Trigger conditions matter for two reasons:

1. They prevent unwanted runs. A Condition action inside the flow stops the logic, but the run — and its API requests against your daily entitlement — already happened. A trigger condition stops the run from ever being created.
2. They break infinite loops. The classic exam scenario: a flow triggers on row modification and then updates the same row, re-triggering itself forever. Fixes: add a trigger condition (for example, requiring a status value that the flow's own update removes), narrow Select columns to columns the flow never updates, or compare the last-modified-by user against the flow's service account.

Split On and Concurrency (Awareness Level)

Two trigger Settings appear in exam 'how many runs?' questions:

• Split On — enabled by default for triggers that can return an array (for example, SharePoint 'When items are created or modified'). With Split On, each item in the batch gets its own run. Disable it when you want one run that receives the whole array — for instance, to process 50 new rows in a single transaction. When concurrency control is on, Split On can debatch a maximum of 100 items per polling cycle.
• Concurrency control — off by default. When enabled, it caps simultaneous runs from 1 to 100, defaulting to 25; excess runs wait in a queue. Set it to 1 to force strictly serial execution when runs must not overlap (for example, updating a shared counter row).

Choosing the Right Trigger: The Exam Table

The pattern: event in a service → automated; person initiates → instant; clock initiates → scheduled. Then refine with Select columns, Filter rows, and trigger conditions so the flow runs exactly when — and only when — it should.