Skip to content

Clarify 'Select columns' behavior in Dataverse triggers with Dynamics 365 entities #1743

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Clarify 'Select columns' behavior in Dataverse triggers with Dynamics 365 entities #1743

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions articles/dataverse/create-update-delete-trigger.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -184,6 +184,19 @@ This property applies to the **Update** condition only. **Create** and **Delete*

This property isn't supported on virtual tables.

> [!NOTE]
> In Dynamics 365 environments—especially when working with standard tables like `account`, `contact`, or other entities part of managed solutions—the **Select columns** property may not behave as expected.
>
> Even if only non-specified columns are modified, the trigger may still fire under certain conditions. This can happen when:
>
> - Server-side components (such as plugins, workflows, or business rules) update or touch the monitored columns in the background.
> - The platform includes the monitored columns in the update payload even if their values have not changed.
> - Model-driven app forms resubmit additional fields automatically on save, including those listed in **Select columns**.

For example, if **Select columns** is set to `mobilephone`, but a user modifies only `emailaddress1`, the flow may still run if a plugin or background process also updates `mobilephone`, or if the system includes `mobilephone` in the update request automatically.

As a result, **the trigger may execute even if only unrelated columns were explicitly changed by the user**. This can lead to unnecessary flow runs, increased API consumption, and incorrect logic branching. To mitigate this, it's recommended to include condition checks within the flow to confirm that meaningful changes have occurred before proceeding.

### 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*.
Expand Down