Trigger flows when a row is added, modified, or deleted

In your flow, select the card for the When a row is added, modified or deleted trigger. A pane opens on the left with the Parameters tab selected.

Trigger condition

The trigger condition, Change type, defines the combination of changes to a row that runs the flow.

When the flow triggers the creation, update, or deletion of a row, the value of triggerOutputs()['body/SdkMessage'] is Create, Update, or Delete, respectively.

When multiple updates occur to a single row in a table, Power Automate evaluates the trigger for each update, even if the updated values are the same as the previous ones. These updates can result in multiple flow runs.

Table name

The Table name list filters rows which rows change before the flow triggers. Learn more in Tables in Dataverse.

The When a row is added, modified or deleted trigger doesn't support triggering flows on relationships of type 1:N or N:N.

Scope

The Scope list indicates those rows should be monitored to determine if the flow should be run.

Here’s what each scope means:

Filter conditions

Use filter conditions to set conditions for when to trigger flows.

Filter columns

Use the Select columns box to define the specific columns of the row that should cause the flow to run when included in the request, as a comma-separated list of unique column names. Only include columns with changed values in update requests. The flow runs when the values included are the same as existing values.

This property applies to the Update condition only. Create and Delete apply to all columns of a row.

This property isn't supported on virtual tables.

Filter expression

The filter expression provides a way for you to define an OData style filter expression to help you to define the trigger conditions even more precisely. The flow runs only when the expression evaluates to true after the change is saved in Dataverse. In the following examples, the flow triggers when firstname is updated to John.

Examples for Filter rows:

firstname eq 'John'

contains(firstname,'John')

Learn more in standard filter operators and query functions.

Set the parameters directly on the card for the When a row is added, modified or deleted trigger.

Trigger condition

The trigger condition, Change type, defines the combination of changes to a row that runs the flow.

When the flow triggers the creation, update, or deletion of a row, the value of triggerOutputs()['body/SdkMessage'] is Create, Update, or Delete, respectively.

When multiple updates occur to a single row in a table, Power Automate evaluates the trigger for each update, even if the updated values are the same as the previous ones. These updates can result in multiple flow runs.

Table name

The Table name list filters rows which rows change before the flow triggers. Learn more in Tables in Dataverse.

The When a row is added, modified or deleted trigger doesn't support triggering flows on relationships of type 1:N or N:N.

Scope

The Scope list indicates those rows should be monitored to determine if the flow should be run.

Here’s what each scope means:

To access the advanced parameters, select Show all in the Advanced parameters field.

Wait condition using delay until

Use an OData-style time stamp in the Delay until property to delay the flow trigger until a specific UTC time.

The key benefit of using the Dataverse Delay until property instead of the standard Delay until action is the Dataverse Delay until property never expires, allowing the flow run to wait for long periods of time.

User impersonation using Run As

The flow owner must have the Microsoft Dataverse privilege Act on Behalf of Another User (prvActOnBehalfOfAnotherUser). The Delegate security role includes this privilege by default. You can enable it on any security role. Learn more in Impersonate another user.

When you create flows with the When a row is added, modified or deleted trigger, you can set each Microsoft Dataverse action in the flow to be performed using the context of a user, other than the flow owner.

To impersonate a user, follow these steps. For each Dataverse action you want to run as a different user, select an option in the Run as dropdown menu.

For the steps where it isn't selected, the default user is assumed. This calls the underlying APIs based on the selected user, not the flow owner. If nothing is specified, it defaults to the flow owner who created the flow—essentially, the author.

Here are the other options:

• Flow owner: The user who created the flow.

• Row owner: The user who owns the Microsoft Dataverse row that changes, triggering the flow. If a team owns a row, this option defaults to running as the flow owner.

• Modifying user: The user who acted on the Microsoft Dataverse row, triggering or modifying the flow.

To access the advanced options, select Show advanced options.

Filter conditions

Use filter conditions to set conditions for when to trigger flows.

Filter columns

Use the Select columns box to define the specific columns of the row that should cause the flow to run when included in the request, as a comma-separated list of unique column names. Only include columns with changed values in update requests. The flow runs when the values included are the same as existing values.

This property applies to the Update condition only. Create and Delete apply to all columns of a row.

This property isn't supported on virtual tables.

Filter expression

The filter expression provides a way for you to define an OData style filter expression to help you to define the trigger conditions even more precisely. The flow runs only when the expression evaluates to true after the change is saved in Dataverse. In the following examples, the flow triggers when firstname is updated to John.

Examples for Filter rows:

firstname eq 'John'

contains(firstname,'John')

Learn more in standard filter operators and query functions.

Unlike the examples in the reference links, your expression must not contain the string $filter=. This string applies only when you use the APIs directly.

Wait condition using delay until

Use an OData-style time stamp in the Delay until property to delay the flow trigger until a specific UTC time.

The key benefit of using the Dataverse Delay until property instead of the standard Delay until action is the Dataverse Delay until property never expires, allowing the flow run to wait for long periods of time.

User impersonation using Run As

The flow owner must have the Microsoft Dataverse privilege Act on Behalf of Another User (prvActOnBehalfOfAnotherUser). The Delegate security role includes this privilege by default. You can enable it on any security role. Learn more in Impersonate another user.

When you create flows with the When a row is added, modified or deleted trigger, you can set each Microsoft Dataverse action in the flow to be performed using the context of a user, other than the flow owner.

To impersonate a user, follow these steps:

1. In the designer, select a value for Run as to specify which user's context Microsoft Dataverse uses for subsequent Dataverse actions.
2. For each Dataverse action you want to run as a different user, select the ellipses (...) in the upper-right corner, and then select Use invoker’s connection.

For the steps where it isn't selected, the default user is assumed. This calls the underlying APIs based on the selected user, not the flow owner. If nothing is specified, it defaults to the flow owner who created the flow—essentially, the author.

Here are the other options:

• Flow owner: The user who created the flow.

• Row owner: The user who owns the Microsoft Dataverse row that changes, triggering the flow. If a team owns a row, this option defaults to running as the flow owner.

• Modifying user: The user who acted on the Microsoft Dataverse row, triggering or modifying the flow.