Rules of Engagement: How Plugins, Workflows, and Power Automate Coexist in the Execution Pipeline

Understanding how the three automation engines interact—Plugins, Classic Workflows, and Power Automate—is essential for designing predictable, scalable, and conflict-free business logic in the Power Platform. Each automation type runs at different layers, at different times, and with different capabilities. When combined without rules, they create race conditions, duplicated logic, inconsistent data, and performance issues.

This guide explains when each tool executes, what they are best suited for, how to avoid conflicts, and how to design the execution pipeline properly.

1. The Dataverse Automation Stack – High-Level View

2. What Runs Where? (Rules of Engagement)

A. Plugins — “First Responders” (Synchronous or Asynchronous)

Where they run:

•  Deep inside the Dataverse execution pipeline
•  Before or after the database commit

Best for:

• Real-time validation
• Enforcing business rules
• Data transformation
• Preventing bad data from saving
• High-performance logic
• Complex parent/child relationship logic
• Custom API execution

Rules of engagement:

Plugins ALWAYS run before Power Automate & classic workflows

Synchronous (real-time) plugins can stop an update/creation

Asynchronous plugins run right after the transaction commits

Plugins see full transaction context (Target, Pre-Image, Post-Image)

Think of plugins as:

The enforcement layer → “clean and validate the data before anything else fires.”

B. Classic Workflows — “Legacy Post-Processing”

Where they run:

• ONLY after the record is saved
• Never before the database write
• Execute within Dataverse async service

Best for:

• Simple post-update logic
• Legacy systems still using workflows
• Send simple notifications
• Background operations

Rules of engagement:

• Workflows cannot prevent data from saving
• Will always run after plugins
• Losing relevance → replaced by Power Automate

Think of workflows as:

The old automation engine still supporting background jobs.

C. Power Automate — “Orchestration Layer”

Where they run:

•  External orchestration platform
• Triggered after Dataverse writes a record
• Not part of the transaction pipeline

Best for:

• Long-running business processes
• Multi-step approvals
• Cross-system automations
• HTTP calls, integrations
• Notifications, reminders
• Orchestrating multiple Dataverse operations

Rules of engagement:

• Triggered after the database update
• Does NOT see pipeline context (no Pre/Post image)
• Does NOT prevent save
• Subject to delay, flow throttling, retry, async nature
• May run twice if not designed correctly

Think of Power Automate as:

 The integration and process orchestration engine.

3. The Real Problem: When All Three Run Together

Without architecture governance, mixed automations cause:

• Duplicate updates
• Infinite update loops
• Conflicts between plugin validation and flow logic
• Race conditions (which automation runs first?)
• Slow performance
• Hard-to-debug business logic

This is why rules of engagement matter.

4. Clear Rules of Engagement for Architects

Rule 1 — Anything that must block or validate MUST be in a plugin.

Because only plugins can stop transactions.

Examples:

• Prevent duplicate records
• Validate SIRET/VAT numbers
• Restrict field changes
• Enforce security

Rule 2 — Anything that requires pipeline images MUST be a plugin

Power Automate does not have Pre/Post images.

Examples:

• Compare old vs new value
• Detect attribute-level changes
• Validate before-save data

Rule 3 — Cross-system integration → Power Automate or Azure Logic Apps

• Plugins should NOT call external HTTP services directly unless absolutely necessary.

Rule 4 — Post-commit processing → Use async plugins or Power Automate

Examples:

• Notifications
• Post-create enrichment
• Case routing
• Background calculations

Rule 5 — Never mix plugin + flow updates on the same field

• This causes endless update loops.

Rule 6 — For reusable business logic → use Custom Actions

Plugins and Flows can both call the same Custom Action.

Custom Action acts like:

• Shared business logic layer
• Versioned API
• Secure execution pipeline

5. Real-World Scenarios: What to Use When

Scenario A — Enforce Blacklist Validation on Account Creation

• Must stop save → Plugin
• Requires Pre-Image → Plugin
• High performance → Plugin

Scenario B — When Account Created, Notify Sales Team

• Simple post-event notification
• Power Automate or async plugin

Scenario C — Prospect integration with Web API

• Power Automate with HTTP Connector

or

• Plugin calling Custom API

Scenario D — Validate IBAN, SIREN, VAT Number

• Needs real-time validation
• Must block save
• Uses regex patterns

→ Plugin

Scenario E — Complex business process

• Multi-step approval
• External users
• Long-running

→ Power Automate Cloud Flow

6. Architectural Summary Table

How They Coexist

The coexistence works only if each automation stays in its lane:

• Plugins = transactional, validation, enforcement, data integrity
• Power Automate = orchestration, integration, long-running workflows
• Workflows = legacy automation (avoid for new solutions)

A good architect ensures:

• Clear ownership of logic
• No duplication
• No race conditions
• Predictable execution order
• High performance
• Maintainability