Detecting Create vs Update Triggers in Dataverse Power Automate Flows

The Dataverse connector's "When a row is added, modified or deleted" trigger fires for multiple operation types. When your flow needs different logic for creates versus updates, here is how to detect which one fired.

The Modern Approach (2026)

The current Dataverse connector provides the trigger type directly in the trigger outputs. Use this expression:

@triggerOutputs()?['body/SdkMessage']

This returns one of:

• Create — a new row was added
• Update — an existing row was modified
• Delete — a row was removed

Implementing Conditional Logic

Add a Switch action right after the trigger:

Switch on: @triggerOutputs()?['body/SdkMessage']

Case: Create

• Set default field values
• Send welcome notifications
• Create related records

Case: Update

• Compare old and new values
• Trigger approval workflows
• Sync changes to external systems

Case: Delete

• Archive the record
• Clean up related data
• Send deletion notifications

Comparing Old and New Values on Update

For updates, you often want to know what actually changed. Unlike a Dataverse plug-in, the Power Automate trigger does not give you pre-operation values — there is no _previousValue_* property on the trigger body, and this is a long-standing gap that the community has open ideas requesting.

Three patterns that work today:

1. Maintain a "last known value" column. When you care about transitions on a specific field (e.g., statuscode), keep a shadow column you write to on every change, and read from on the next run.
2. Use Dataverse audit history. If auditing is on for the table, your flow can call RetrieveRecordChangeHistory to fetch the previous value as part of the run. Heavier than a column compare, but no schema changes.
3. Move the comparison server-side. A real-time Dataverse plug-in registered on PreUpdate has the previous values in its plug-in execution context. Use a plug-in to detect the transition and a flow to react.

Whichever path you pick, do not reach for a property on the trigger body that does not exist.

Filtering Triggers

Instead of detecting the type in-flow, you can filter at the trigger level:

1. In the trigger configuration, set Change type to only the operations you care about
2. Use Filter rows to further narrow which records fire the flow
3. Use Select columns to limit the payload and improve performance

This reduces unnecessary flow runs and keeps your run history clean.

Common Pattern: Single Trigger, Shared Logic

For flows where create and update share most logic but differ in a few steps:

1. Run shared validation and data enrichment first
2. Use a Condition to branch only where behavior differs
3. Converge back to shared post-processing

This avoids maintaining two nearly identical flows for create and update scenarios.

Key Takeaway

Use triggerOutputs()?['body/SdkMessage'] to detect the operation type. Filter at the trigger level when possible to reduce unnecessary runs. And remember: the trigger does not expose pre-update values — keep that comparison server-side or use a shadow column rather than chasing a property that isn't there.