What it does

The Microsoft Dataverse connector starts flows when data changes in Dataverse and gives you the row-level actions to read and write it. It's the connector you build model-driven app automation on, and the one most Power Platform solutions end up leaning on hardest.

Key facts

• Triggers: When a row is added, modified or deleted, When a row is selected, and When an action is performed. Actions cover create, update, get, list, delete, relate/unrelate, changesets, file and image upload/download, and bound/unbound actions.
• The row trigger needs the flow owner to hold user-level create, read, write and delete on the Callback Registration table, plus read on the table being watched.
• Scope controls which rows are watched: User, Business Unit, Parent: Child business unit, or Organization.
• Select columns filters update triggers to named columns. Lookup columns aren't supported there — specify one and changes to it won't fire the flow. Use scalar types only.
• The filter expression takes OData syntax (firstname eq 'John', contains(firstname,'John')) and the flow runs only when it evaluates true after the change is committed.
• The row trigger doesn't fire on 1:N or N:N relationship changes.
• Run as lets each Dataverse action run in the context of flow owner, row owner, or modifying user. The flow owner needs the Act on Behalf of Another User privilege — the Delegate security role has it by default.
• The Dataverse Delay until trigger property never expires, unlike the Delay until action, so it handles long waits.

When to use / skip

This is the default for anything event-driven inside a Dataverse-backed solution — it's not premium-class, it's transactional rather than polled, and it respects security scope. Skip it where a plug-in or a real-time workflow is the better fit: if you need the logic inside the database transaction, or you need synchronous validation that can block the save, a flow running asynchronously afterwards is the wrong tool.

Configuration decisions

• Scope: Organization is the honest answer for most system automation, but it's also the one that turns a small change into a tenant-wide event storm. Pick deliberately.
• Whether to filter with Select columns, a filter expression, or both — and whether the filtering happens in the trigger or in a condition afterwards, which costs you a run either way.
• Which identity the Dataverse actions run under, and whether Run as impersonation is needed for audit trails to look right.
• FetchXML versus OData in List rows: FetchXML for aggregates, link-entity joins and anything you'd write in advanced find; OData filter for simple predicates.
• Whether the flow is solution-aware with a connection reference, which it should be if it's touching Dataverse at all.

Gotchas

• Self-triggering loops are the classic failure. A flow that triggers on update of a table and then updates a row in that table will trigger itself. Guard it with a trigger condition that checks the value isn't already what you're about to set, and add a Terminate as a backstop.
• Multiple updates to the same row each evaluate the trigger, even when the new values match the old ones. Repeat runs are normal, not a bug.
• Don't put always-present columns like the primary key in Select columns — every update includes them, so every update triggers the flow.
• Trigger fires on inclusion in the update request, not on the value actually changing. A form save that writes an unchanged field still counts.
• List rows pages by default. Without pagination turned on and a sensible page size you'll silently process the first tranche and think the job's done.

Consultant notes

• Loop protection is a design standard, not a per-flow decision. Agree the pattern once with the team and apply it to every Dataverse-triggered flow.
• Warn the client that Dataverse triggers are asynchronous. Users who expect a field to be populated the instant they hit save will raise it as a defect; set that expectation in UAT, not after go-live.
• Scope and Run as together decide what the audit trail says. Finance and compliance stakeholders care about this more than the project team expects — get it agreed before build.

---

Worth a look after each release wave; the trigger's filtering and Run as options have both gained capability recently