9.2 Dataverse Connector Triggers & Operational Filters

Dataverse Connector Triggers & Operational Filters

The Microsoft Dataverse connector provides the primary integration pipeline between Microsoft Dataverse and Power Automate cloud flows. Unlike generic polling connectors, the unified Dataverse connector integrates directly with the Dataverse Event Execution Pipeline via high-performance, asynchronous webhooks. For the PL-200: Microsoft Power Platform Functional Consultant exam, you must demonstrate mastery over trigger event types, organizational scope boundaries, OData query filters, schema attribute filtering, execution security contexts, and custom action triggers.

---

1. The Dataverse Trigger Architecture

The core trigger for Dataverse automation is When a row is added, modified or deleted. This trigger replaces legacy Common Data Service (CDS) and Dynamics 365 connectors, providing native support for solutions, connection references, and enterprise security models.

+-----------------------------------------------------------------------------+
|                   DATAVERSE EVENT PROCESSING PIPELINE                       |
|                                                                             |
|   [DATAVERSE DATABASE EVENT] (Create / Update / Delete)                     |
|                 |                                                           |
|                 v                                                           |
|   +---------------------------------------+                                 |
|   |           1. SCOPE FILTER             |  <-- Evaluates User / BU /      |
|   | Is record owner within target scope?  |      Parent-Child / Org scope   |
|   +---------------------------------------+                                 |
|                 | (Pass)                                                    |
|                 v                                                           |
|   +---------------------------------------+                                 |
|   |         2. SELECT COLUMNS             |  <-- Did any specified columns  |
|   | Were targeted attributes modified?    |      change? (Prevents loops!)  |
|   +---------------------------------------+                                 |
|                 | (Pass)                                                    |
|                 v                                                           |
|   +---------------------------------------+                                 |
|   |          3. FILTER ROWS               |  <-- Evaluates OData expression |
|   | Does record meet OData criteria?      |      (e.g., statuscode eq 1)    |
|   +---------------------------------------+                                 |
|                 | (Pass)                                                    |
|                 v                                                           |
|   +---------------------------------------+                                 |
|   |         4. TRIGGER CONDITIONS         |  <-- Evaluates WDL expressions  |
|   | Do advanced @settings expressions pass|      in trigger Settings tab    |
|   +---------------------------------------+                                 |
|                 | (Pass)                                                    |
|                 v                                                           |
|   [INSTANTIATE CLOUD FLOW RUN] (Under configured 'Run as' identity)         |
+-----------------------------------------------------------------------------+

Change Types

The Change type parameter determines which database lifecycle events activate the trigger:

• Added: Fires when a new record is inserted (Create event).
• Modified: Fires when an existing record is updated (Update event).
• Deleted: Fires when an existing record is deleted (Delete event).
• Added or Modified: Fires on both creation and subsequent updates (Upsert event).
• Added or Deleted: Fires when records are inserted or removed.
• Modified or Deleted: Fires on record updates or removals.
• Added, Modified or Deleted: Universal trigger firing on all database state changes.

---

2. Trigger Scope Configuration

The Scope parameter defines the organizational boundary within the Dataverse business unit hierarchy where record modifications will be intercepted.

+-----------------------------------------------------------------------------+
|                        DATAVERSE TRIGGER SCOPES                             |
|                                                                             |
|   [ORGANIZATION]                ---> Triggers tenant-wide across ALL BUs    |
|                                                                             |
|   [PARENT: CHILD BUSINESS UNITS]---> Triggers in user's BU & ALL child BUs  |
|                                                                             |
|   [BUSINESS UNIT]               ---> Triggers ONLY in user's direct BU      |
|                                                                             |
|   [USER]                        ---> Triggers ONLY on records owned by      |
|                                      the flow owner / triggering user       |
+-----------------------------------------------------------------------------+

Scope Hierarchy & Security Boundaries

[!CAUTION] Scope Mismatch Failures: If a flow is configured with Scope set to Business Unit or User, and a record is created by a user in a different business unit, the flow will NOT trigger, even if the flow owner has System Administrator privileges. Default to Organization scope for enterprise-wide background automations unless strict departmental isolation is required.

---

3. Operational Filtering: Select Columns & Filter Rows

High-volume Dataverse environments require precise operational filtering to optimize platform throughput, reduce API consumption, and prevent catastrophic infinite trigger loops.

Select Columns (Attribute-Level Trigger Filtering)

When a flow monitors the Modified or Added or Modified change type, Dataverse triggers by default whenever any column on the record is updated. This introduces two major risks:

1. Unnecessary Executions: Updating an unrelated column (e.g., updating a phone number) triggers a flow meant only to process credit limit increases.
2. Infinite Trigger Loops: If Flow A triggers on Account modification, and Action Step 3 updates the Account's LastProcessedDate column, the update action causes Dataverse to fire Flow A again, creating an infinite recursive execution loop.

To resolve this, populate the Select columns property with a comma-separated list of schema column names:

statuscode,creditlimit,telephone1,cr123_approvalstage

With Select columns configured, Dataverse fires the trigger only if one or more of the specified columns were modified during the transaction.

Filter Rows (Server-Side OData Query Filtering)

The Filter rows property evaluates standard OData v4 expressions at the Dataverse database layer before instantiating a cloud flow run. If the expression evaluates to false, Dataverse discards the event without consuming Power Automate run quota.

// Example 1: Active Accounts with Revenue exceeding 100,000
statecode eq 0 and revenue gt 100000

// Example 2: Specific Choice Column Value (Approved status)
statuscode eq 864500001

// Example 3: Text column starts with prefix and lookup is populated
startswith(accountnumber, 'CORP') and _primarycontactid_value ne null

// Example 4: Date comparison (Created on or after specific date)
createdon ge 2026-01-01T00:00:00Z

Common OData Operators for PL-200

Trigger Conditions (Settings Tab)

In addition to Filter Rows, makers can configure Trigger Conditions in the trigger's Settings > Trigger Conditions pane using Power Automate Workflow Definition Language (WDL) expressions:

@equals(triggerOutputs()?['body/statuscode'], 864500001)
@and(greater(triggerOutputs()?['body/revenue'], 50000), not(empty(triggerOutputs()?['body/emailaddress1'])))

All configured trigger condition lines must evaluate to true for the flow to execute.

---

4. Run-As Execution Identity & Security Context

When a Dataverse-triggered flow executes downstream actions (such as reading sensitive records or updating related tables), the permissions evaluated by Dataverse depend on the trigger's Run as configuration.

+-----------------------------------------------------------------------------+
|                     DATAVERSE 'RUN AS' EXECUTION IDENTITIES                 |
|                                                                             |
|   [FLOW OWNER (DEFAULT)]                                                    |
|   - Runs under the identity and security roles of the flow creator/owner    |
|   - Uniform execution regardless of who triggered the change in Dataverse   |
|   - Ideal for system-level integrations and automated data transformations  |
|                                                                             |
|   [TRIGGERING USER]                                                         |
|   - Impersonates the exact user who performed the database modification     |
|   - Actions respect that user's specific Dataverse security roles and depth |
|   - Write/Update actions tag the triggering user in 'Modified By' columns   |
|                                                                             |
|   [RECORD OWNER] / [MODIFYING USER]                                         |
|   - Impersonates the user assigned as the owner of the modified row         |
|   - Ideal for routing tasks and activities on behalf of account managers    |
+-----------------------------------------------------------------------------+

[!IMPORTANT] Security Implications of Triggering User: When Run as is set to Triggering user, if User A modifies a record that triggers a flow containing an action to read a restricted financial table, the flow will FAIL with an AccessDenied error if User A does not possess Read privileges on that financial table. Ensure security roles are appropriately assigned when using user impersonation.

---

5. The 'When an action is performed' Trigger

Beyond basic table row mutations, Microsoft Dataverse allows developers and functional consultants to define custom business operations called Custom Process Actions and Custom APIs. Cloud flows can intercept these invocations using the When an action is performed trigger.

+-----------------------------------------------------------------------------+
|                 'WHEN AN ACTION IS PERFORMED' ARCHITECTURE                  |
|                                                                             |
|   [DATAVERSE CUSTOM API / ACTION INVOCATION]                                |
|   (Called via JavaScript, C# Plug-in, Power Pages, or External REST API)    |
|                 |                                                           |
|                 v                                                           |
|   [TRIGGER: When an action is performed]                                    |
|   - Catalog: Core / Custom Business Domain                                  |
|   - Category: Sales, Service, or Custom Category                            |
|   - Table name: (Optional: Bound to Account/Contact or Unbound/Global)      |
|   - Action name: contoso_CalculateCreditRiskScore                           |
|                 |                                                           |
|                 v                                                           |
|   [ACCESS ACTION INPUT & OUTPUT PAYLOADS]                                   |
|   - Parses complex JSON parameters passed into the action                   |
|   - Executes downstream logic and returns calculated results                |
+-----------------------------------------------------------------------------+

Bound vs. Unbound Actions

• Bound Actions: Tied to a specific Dataverse table (e.g., contoso_ApproveInvoice bound to Invoice). The trigger requires selecting the Table Name and provides the targeted row GUID (Target/accountid).
• Unbound (Global) Actions: Not associated with any specific table (e.g., contoso_SendTenantBroadcast). The Table Name is set to (none), and the action accepts global parameters.