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
Summary: 

The Dataverse execution pipeline orchestrates how business logic runs when data changes occur in Dynamics 365 and the Power Platform. Plugins, classic workflows, and Power Automate flows each play a unique role, and understanding how they coexist ensures predictable, high-performance, and maintainable solutions.

Plugins operate closest to the database and run synchronously or asynchronously within the Dataverse pipeline. They are best suited for real-time validation, complex business logic, and operations requiring transactional consistency. Because plugins execute fastest and support pre/post stages, they are ideal for critical logic that must not fail.

Workflows, although legacy, still serve well for simple asynchronous automation. They run after the database transaction has completed, reducing risk but limiting their use for real-time requirements.

Power Automate interacts with Dataverse externally through events. It is excellent for long-running processes, integrations, approvals, and cross-system actions. However, because it relies on triggers and APIs outside the pipeline, it cannot ensure transactional rollback and is not appropriate for logic requiring real-time enforcement.

A well-architected system uses a pipeline-first strategy, placing essential business rules in plugins, allowing workflows where simplicity is needed, and using Power Automate for integrations or user-facing processes. Following clear rules of engagement avoids duplication, race conditions, and performance bottlenecks while ensuring predictable behavior across the platform.

Comments

Post a Comment

Popular posts from this blog

Effective Strategies for Debugging Plugins in Dynamics CRM

Image
In a recent interview, I was asked about debugging plugins in Dynamics CRM. The interviewer specifically wanted to know my approach to plugin debugging. In response, I mentioned using the Plugin Registration Tool profiler. However, I later realized there are multiple methods to debug plugins in Dynamics CRM/Dataverse, each essential for efficient troubleshooting. Debugging plays a crucial role in development, and having a solid understanding of various debugging approaches can help streamline issue resolution in Dynamics 365. Here, I'll explore different techniques for debugging plugin code. There are below options to use in the plugin in Dynamics CRM/Dataverse ITracingService : In Dynamics CRM plugin development, ITracingService is a service provided within the plugin's execution context that logs information for tracing and debugging. It allows developers to capture real-time. Plugin Profiler : A plugin profiler in Dynamics CRM (or Dataverse) is a debugging tool in the Plugi...
Read more

Connecting the Dots: FetchXML and Web API Integration in Dataverse

Image
 In Dataverse, FetchXML and the Web API are two powerful mechanisms for retrieving data and interacting with entities. Here's a brief overview of each and how they can be integrated: 1.    FetchXML :      -   Definition:   FetchXML is a proprietary query language used in Microsoft Dynamics 365 and Dataverse for querying data from entities.    -   Usage:   FetchXML queries can be used to retrieve data based on complex criteria, perform aggregations, and filter records.    -   Features:   FetchXML supports various query expressions, including conditions, sorting, grouping, and aggregation functions.    -   Integration:   FetchXML queries can be executed programmatically using client-side scripting, server-side code, or through tools like the Dynamics 365 Web API. 2.    Web API :      -   Definition:  ...
Read more

Exploring the Differences: Managed vs. Unmanaged Solutions in Dynamics CRM/Dataverse

Image
In Dynamics CRM/Dataverse, solutions are central to Application Lifecycle Management (ALM) , providing a structured way to manage, package, and distribute customizations across environments. Microsoft uses solutions to transfer apps and customizations by exporting them from one Dataverse environment and importing them into another.  Each solution is authored and maintained by a publisher and includes components like Power Apps (canvas and model-driven), flows, entities, forms, connectors, web resources, and configurations—excluding business data. Solutions streamline ALM practices within Microsoft Power Platform. In Dynamics CRM/Dataverse, there are two types of solutions: Managed and Unmanaged . When planning an implementation, it’s important to understand the advantages and disadvantages of each to make an informed decision. Let’s explore both types to determine the best approach for development and deployment. In Dynamics 365 CRM, a managed solution is a fully packaged solution ...
Read more

Decode and Fix: “This Data Type is Unsupported for Evaluation” in Power Apps

Image
 One common frustration when building Canvas Apps over Dataverse is encountering this cryptic error:  “This data type is unsupported for evaluation” This message typically appears when Power Apps cannot process or render a specific Dataverse column type within a control or formula. While it may seem vague, it’s usually tied to specific patterns involving complex column types or runtime data structure mismatches. In this blog, we'll explore common causes, scenarios, and practical fixes from both a developer and architectural standpoint. Root Causes of the Error 1. Polymorphic Lookups Dataverse supports polymorphic relationships (e.g., `Owner`, `Customer`, `Regarding`) that can point to multiple entity types. These lookups can't be directly evaluated in Power Apps unless you cast the reference explicitly. Use: If(     IsType(ThisItem.Customer, Account),     AsType(ThisItem.Customer, Account).Name,     AsType(ThisItem.Customer, Contact).FullName ) 2....
Read more

How to Write and Understand a Dynamics CRM Plugin

Image
 Here’s a sample plugin code in Dynamics CRM written in C#, along with a detailed explanation of each line. This plugin will update the "Description" field of an entity whenever a record is created. Sample Plugin Code using System; // For basic .NET types using Microsoft.Xrm.Sdk; // Provides key interfaces for CRM plugin development using Microsoft.Xrm.Sdk.Query; // For performing queries against CRM data namespace SamplePluginNamespace // Custom namespace for the plugin { public class SamplePlugin : IPlugin // Plugin class implementing the IPlugin interface { public void Execute(IServiceProvider serviceProvider) { // STEP 1: Retrieve the context of the plugin IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); if (context.MessageName != "Create" || context.St...
Read more

L1, L2, and L3 Support Explained

Image
  L1, L2, and L3 Support Explained In IT and software support, L1 (Level 1), L2 (Level 2), and L3 (Level 3) represent different tiers of technical support, each handling issues of varying complexity. 1️⃣ L1 Support (Level 1 - Frontline Support) Role: First point of contact for users/customers Responsibilities: Handles basic issues such as password resets, user access, and general troubleshooting. Uses a knowledge base or predefined scripts to resolve common problems. Escalates complex issues to L2 if not resolved. Communicates with customers via phone, chat, or email. Records tickets in a helpdesk system (e.g., ServiceNow, Jira, Zendesk). 🔹 Example: A user is unable to log in due to incorrect credentials → L1 resets the password. 2️⃣ L2 Support (Level 2 - Technical Support) Role: More in-depth troubleshooting and problem-solving Responsibilities: Resolves moderate to complex technical issues that L1 cannot handle. Analyzes logs, configurations, and system...
Read more

Model-Driven Apps Command Bar: A Guide to PrimaryControl and SelectedControl

Image
The command bar in Power Apps model-driven apps is a toolbar that lets users perform actions. You can customize it by adding buttons that run your own logic, either using Power Fx or JavaScript. This logic can work with a single data record or multiple records, depending on where the button is placed. The CrmParameter in the ribbon of Dynamics CRM (now Dynamics 365) is a special parameter used in the ribbon's button definitions or commands. It provides contextual information about the entity or record within the CRM system when the ribbon button is clicked. Purpose of CrmParameter CrmParameter is primarily used to pass specific CRM-related data to a custom JavaScript function, URL, or command action. It helps in retrieving dynamic data based on the current context, such as entity IDs, selected records, or even the page's user interface settings. 1. PrimaryControl Definition : Refers to the main form context or entity record currently being displayed or interacted with in the ap...
Read more

Plugin Execution Pipeline Demystified: A Must-Know for CRM Architects

Image
If you design or operate Microsoft Dynamics 365/Dataverse solutions, understanding the Plugin Execution Pipeline is essential. Plugins are the primary extensibility mechanism for implementing server-side business logic. This guide explains the pipeline in plain, technical terms, shows where and how plugins run, and lists practical guidance for reliable, performant solutions. 1) What is the Plugin Execution Pipeline? The pipeline is the ordered set of stages and execution contexts in which server-side events (messages) are processed. When an operation (Create, Update, Delete, Assign, Retrieve, etc.) occurs, Dataverse builds a request execution pipeline and executes registered plugin steps at configured stages. Plugins can inspect and modify data, cancel operations, and trigger side effects. 2) High-level flow (what happens during an operation) Client/API call (UI, Web API, SDK) initiates an operation. Platform core logic performs pre-checks and builds the execution context. Plugin ste...
Read more

Stop Struggling with Plugins: Learn IOrganizationService the Smart Way

Image
Have you ever deployed a Dataverse plugin, only to watch it fail silently or act unpredictably? Most of the time, the missing piece is understanding how to communicate with Dataverse the smart way—using IOrganizationService . In the world of Dataverse, every plugin waits for its turn when something changes. The plugin looks around and wonders, “How do I talk to the database?” That’s when IOrganizationService steps in like a trusted messenger, ready to carry out requests and bring back results. “ Need to create a record? I can handle that,” it says. “ Want to update or delete data safely ? Leave it to me.” It even speaks the secret language of Dataverse messages like Assign and SetState . But it never works alone— IOrganizationServiceFactory brings it to life, deciding whether it should act as the user or as the powerful system account. Working together with IPluginExecutionContext , it always knows who triggered the action, which record is involved, and when to respond. What is IOrgan...
Read more

Step-by-Step Guide to Building Custom APIs in Dataverse

Image
Custom APIs in Microsoft Dataverse allow developers and architects to create their own reusable, secure, and well-defined service endpoints that extend the standard Dataverse Web API. Instead of relying solely on out-of-the-box messages (like Create, Update, or Retrieve ), Custom APIs let you define your own business operations — complete with input and output parameters — that encapsulate complex logic and can be called from Power Automate, Power Apps, or external systems. These APIs are registered once and behave like native Dataverse operations, making them ideal for implementing domain-specific logic, integrating with external services, or simplifying client-side development. From a technical standpoint, a Custom API can be implemented through a plugin class, where the backend logic is written in C#. Developers can control security through privilege definitions and ensure consistency by centralizing key business rules. Custom APIs are particularly valuable in enterprise environmen...
Read more