Trigger flows when a row is added, modified, or deleted
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.
To create a flow that triggers when you create, modify, or delete a row, you must have user-level permissions for create, read, write, and delete on the Callback Registration table.
Additionally, depending on the scopes defined in the flow, you might need at least that level of read on the same table. You can get more information about Environment security.
The following information is required to use the When a row is added, modified or deleted trigger.
The trigger condition, Change type, precisely defines which combination of changes to a row would run the flow.
When the flow is triggered by the creation, update, or deletion of a row, the value of
triggerOutputs()['body/SdkMessage'] will be
The Table name list filters the rows to indicate precisely which kind of rows should change before the flow triggers. See Tables in Dataverse.
The When a row is added, modified or deleted trigger doesn't support virtual tables. The When a row is added, modified or deleted trigger doesn't support starting flows on relationships of type 1:N or N:N.
The Scope list indicates those rows should be monitored to determine if the flow should be run.
Here’s what each scope means:
|Scope||Row ownership level|
|Business Unit||Actions are taken on rows owned by anyone in your business unit.|
|Organization||Actions are taken by anyone within the environment.|
|Parent: Child business unit||Actions are taken on rows that are owned by anyone in your business unit or a child business unit.|
|User||Actions are taken on rows owned by you.|
You can set additional properties to define more granularly when the flow runs and the user profile under which it runs.
Use filter conditions to set conditions for when to trigger flows.
Use the Column filter box to define the specific columns of the row that should cause the flow to run when changed, as a comma-separated list of unique column names.
This property applies to the Update condition only. Create and Delete apply to all columns of a row.
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 example, the flow triggers when
firstname is updated to "John".
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. For more details, go to 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.
Follow these steps to impersonate a user:
In the Power Automate flow definition, select Show advanced options in the When a row is added, modified or deleted trigger.
Select a value for Run as to tell Microsoft Dataverse which user’s context you intend to use for subsequent Dataverse actions.
For each Dataverse action that you want to run as a different user, select the menu in the upper-right corner (...), as shown in the following image, and select the Use invoker’s connection setting. For the steps in which it is not selected, the default user is assumed. This would call the underlying APIs as per the selected user, and not as 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 underwent a change, causing the flow to be triggered. If a row is owned by a team, then this option falls back to run as the flow owner.
Modifying user: The user that took the action on the Microsoft Dataverse row, causing the flow to get triggered or modified.
Additionally, instant flows allow running the steps of any other connector (such as Microsoft Teams, Microsoft 365 Outlook, or SharePoint in the same flow using the invoker’s connection. To do so, follow these steps:
Go to the flow overview page.
Select Edit on the Run only users settings.
In the Manage run-only permissions pane, go to the User and groups tab, and then select Provided by run-only user under the Connections Used list.
Iesniegt un skatīt atsauksmes par