8.1 Dataverse connector triggers/actions, trigger filters & retry policies

Power Automate cloud flows come in three core shapes for the PL-400 exam: automated flows that start from an event (a new email, a Dataverse row change), instant flows that a user or another flow triggers manually or on demand, and scheduled flows that run on a recurrence. For a Dataverse developer, the workhorse trigger is the Microsoft Dataverse connector's row trigger, and understanding exactly how to configure it — and how to control retries when a downstream step fails — is core exam material.

The Dataverse Row Trigger

The trigger commonly labeled "When a row is added, modified, or deleted" (the connector itself is named Microsoft Dataverse, the successor to the older "Common Data Service (current environment)" connector) fires a flow whenever a Dataverse record matching its configuration changes. Its key settings:

Scope matters for solution design: a trigger scoped to Organization watches every matching row regardless of owner, while User scope only watches rows owned by the flow's owner — a common cause of "the flow didn't fire" support tickets when a developer assumes organization-wide coverage.

Select Columns vs. Filter Rows

These two settings are often confused on the exam. Select Columns is a comma-separated list of column logical names; the trigger only fires if the change itself touched one of those columns. Filter Rows is a full OData filter expression (for example, statuscode eq 1) evaluated against the row's current state — it does not care which column changed, only whether the row matches the filter after the change. A robust trigger design frequently combines both: Select Columns narrows when to look, and Filter Rows narrows what state qualifies before a run is even created.

Trigger Conditions for Precise Control

Beyond Select Columns and Filter Rows, the trigger's advanced Settings expose a Trigger Conditions field that accepts one or more Workflow Definition Language expressions, such as:

@equals(triggerBody()?['statuscode'], 191920000)

Trigger Conditions evaluate before a flow run is even created, so they are the cheapest and most precise gate available. This is the standard technique for preventing a flow from re-triggering itself in an infinite loop when its own actions write back to the same row: the condition checks that a specific field actually reached a target value rather than firing on every save, including saves the flow itself caused.

Run As: Flow Owner vs. Triggering User

Run As decides whose security context subsequent Dataverse actions execute under:

• Flow Owner (the default) — the flow always runs with the owner's privileges, regardless of who made the change. Useful when the flow must perform actions the triggering user doesn't have permission for.
• Modifying User (Triggering User) — the flow runs with the permissions of whoever caused the trigger. Useful for auditability and for enforcing that the flow can't act beyond what the acting user is already allowed to do.

Choosing the wrong option is a common design defect: a flow set to Flow Owner can silently perform actions a low-privilege user should never be able to trigger, which is exactly the kind of "assess impact of Power Platform security features" scenario this exam tests.

Dataverse Actions

Once triggered, flows use the Microsoft Dataverse connector's action set to work with data:

• List rows — query with either an OData filter/select or a raw FetchXML query (useful for aggregates, complex joins, or logic ported from an existing view)
• Get a row by ID, Add a new row, Update a row, Delete a row
• Relate rows / Unrelate rows — associate or disassociate records across an N:N relationship
• Perform a bound action / Perform an unbound action — invoke custom APIs or built-in message actions

Retry Policies

Every action (and most triggers) exposes a Settings → Retry Policy control with four options: Default (an exponential backoff that retries a failed call automatically), None, Fixed Interval, and Exponential Interval (with a configurable count and interval). The default policy retries several times with a growing wait between attempts, which is appropriate for transient failures like throttling. A developer should, however, explicitly set Retry Policy: None on actions that are not idempotent — for example, an action that creates a new row — because an automatic retry after a network timeout could create a duplicate record even though the original request actually succeeded server-side. Recognizing when the default retry behavior is unsafe, and overriding it deliberately, is a practical skill the exam expects.