12.1 Classic Dataverse Workflows: Real-Time vs. Background (Async)

Classic Dataverse Workflows: Real-Time vs. Background (Async)

In Microsoft Dataverse, business process automation historically relied on Classic Workflows (formerly known as Dynamics CRM Workflows). Although Microsoft Power Automate Cloud Flows have become the primary, modern orchestration engine for multi-system and event-driven automation across the Power Platform, Classic Dataverse Workflows remain a critical, deeply integrated component of the platform architecture. On the PL-200 certification exam, you must understand how classic workflows execute, their synchronous and asynchronous processing characteristics, and the precise scenarios where they continue to provide architectural advantages over cloud flows.

---

1. Architecture of Classic Dataverse Workflows

Classic Dataverse Workflows are built directly into the Dataverse server infrastructure and operate within the core event execution pipeline. Workflows are classified into two distinct execution modes based on how and when the Dataverse engine processes their logic:

+-----------------------------------------------------------------------------------+
|                     DATAVERSE WORKFLOW EXECUTION PIPELINES                        |
|                                                                                   |
|  [CLIENT / API REQUEST]                                                           |
|          |                                                                        |
|          v                                                                        |
|  +-----------------------------------------------------------------------------+  |
|  |                     SYNCHRONOUS TRANSACTION PIPELINE                        |  |
|  |                                                                             |  |
|  |   [Stage 20: Pre-Operation]                                                 |  |
|  |   --> Real-Time Workflow (Before database write)                            |  |
|  |       * Can validate, modify payload, or cancel with custom error           |  |
|  |                                                                             |  |
|  |   [Stage 30: Main Database Operation (INSERT / UPDATE / DELETE)]            |  |
|  |                                                                             |  |
|  |   [Stage 40: Post-Operation]                                                |  |
|  |   --> Real-Time Workflow (After database write, inside transaction)         |  |
|  |       * Creates related records, updates fields, or rolls back              |  |
|  +-----------------------------------------------------------------------------+  |
|          |                                            |                           |
|   (Commit Database)                            (Queue Async Job)                  |
|          |                                            |                           |
|          v                                            v                           |
|  [UI / CALLER RECEIVES]                  +-----------------------------+          |
|  [SYNCHRONOUS RESPONSE]                  |    AsyncService QUEUE       |          |
|                                          | - Evaluates available pool  |          |
|                                          | - Retries on failure        |          |
|                                          | - Runs Background Workflow  |          |
|                                          +-----------------------------+          |
+-----------------------------------------------------------------------------------+

Real-Time (Synchronous) Workflows

• Pipeline Integration: Real-Time Workflows run directly inside the Dataverse database transaction pipeline.
• Execution Stages:
  • Pre-operation (Before): Executes before the primary database operation is committed. This stage allows the workflow to inspect incoming values, perform complex validation, and abort the transaction before any physical SQL write occurs.
  • Post-operation (After): Executes after the primary record is updated in the database but before the transaction is committed. Any database updates or child record creations initiated by the workflow in this stage participate in the identical SQL transaction.
• User Experience: The user interface (or API caller) is blocked and waits until all real-time workflow logic completes. If an operation succeeds, the UI refreshes immediately with the updated values. If an error occurs, the entire transaction rolls back, and a custom error message is displayed to the user.
• Execution Identity: Can execute under the security context of the Calling User (the user who initiated the change) or the Workflow Owner (elevated administrative privilege).

Background (Asynchronous) Workflows

• Decoupled Processing: When a trigger condition is met, Dataverse writes a lightweight job request to the asynchronous operations queue (asyncoperation table). The primary transaction commits immediately without waiting for the workflow.
• The Asynchronous Processing Service (AsyncService): A dedicated background server pool periodically polls the queue, instantiates the workflow engine, and executes the configured steps out-of-band.
• System Impact & Resiliency: Because execution is decoupled from the user interface, background workflows do not slow down form saves or API response times. Furthermore, if a transient system error occurs (such as a database deadlock or temporary throttling), the AsyncService automatically retries the operation multiple times with exponential backoff.
• Execution Identity: Always executes under the security context of the Workflow Owner.

---

2. Trigger Events, Scope, and Execution Security

Classic workflows provide granular trigger filtering to ensure that automation runs only when precise data conditions are met.

Supported Trigger Events

+-----------------------------------------------------------------------------+
|                        CLASSIC WORKFLOW TRIGGER EVENTS                      |
|                                                                             |
|   1. RECORD IS CREATED        ---> Fires immediately upon row insertion     |
|   2. RECORD STATUS CHANGES    ---> Fires when statecode/statuscode shifts   |
|   3. RECORD IS ASSIGNED       ---> Fires when OwnerId changes               |
|   4. RECORD FIELDS CHANGE     ---> Fires when specific attributes update    |
|   5. RECORD IS DELETED        ---> Fires before or after row removal        |
|   6. AS AN ON-DEMAND PROCESS  ---> Manually executed by users from grid/form|
|   7. AS A CHILD PROCESS       ---> Called explicitly by parent workflows    |
+-----------------------------------------------------------------------------+

1. Record is created: Executes when a new row is inserted into the table.
2. Record status changes: Executes when the record's state changes (e.g., Active to Inactive, Open to Won, Active to Resolved).
3. Record is assigned: Executes when ownership of the record transfers to another user or team.
4. Record fields change (Attribute Filtering): Executes when one or more designated columns are modified. Selecting specific columns is vital for performance to prevent the workflow from firing unnecessarily on unrelated field edits.
5. Record is deleted:
   • In Real-Time workflows, deletion triggers can execute Before (Pre-operation) to inspect or archive data before the row is purged, or to cancel the deletion.
   • In Background workflows, deletion triggers execute After the row has been removed from the database.

Workflow Scope Configuration

The Scope setting defines the organizational boundary within which a user's action will trigger the workflow:

• User: The workflow executes only when the record being modified is owned by the user running the workflow.
• Business Unit: The workflow executes if the record being modified is owned by any user residing within the same Business Unit as the user initiating the action.
• Parent-Child Business Units: The workflow executes if the record is owned by a user in the caller's Business Unit or any of its subordinate child Business Units.
• Organization: The workflow executes globally across the entire Dataverse environment, regardless of who owns the record or what Business Unit they belong to. (This is the most common setting for enterprise business logic).

Execution Identity: Calling User vs. Workflow Owner

When authoring a Real-Time workflow, the consultant must configure the Execute as setting:

• The user who made changes (Calling User): The workflow executes within the security privileges of the logged-in user. If the user does not possess write privileges on a secondary table that the workflow attempts to update, the workflow fails and aborts the entire transaction.
• The owner of the workflow: The workflow executes under the elevated privileges of the user who published the workflow (typically a System Administrator or Service Principal). This allows standard users to trigger workflows that create or update restricted compliance records without granting those users direct security privileges to the target table.

---

3. Workflow Actions and Step Catalog

The classic workflow designer provides a structured, no-code visual step builder. The available action building blocks include:

+-----------------------------------------------------------------------------+
|                        CLASSIC WORKFLOW ACTION CATALOG                      |
|                                                                             |
|   [DATA OPERATIONS]         [FLOW CONTROL]          [COMMUNICATION]         |
|   - Create Record           - Check Condition       - Send Email            |
|   - Update Record           - Conditional Branch    - Send Direct Email     |
|   - Assign Record           - Default Action                                |
|   - Change Status           - Parallel Wait Branch  [TERMINATION]           |
|                             - Start Child Workflow  - Stop: Succeeded       |
|                                                     - Stop: Canceled (Error)|
+-----------------------------------------------------------------------------+

Detailed Action Steps

• Create Record: Provisions a new row in any standard or custom table and populates its columns using static values or dynamic values from the triggering record.
• Update Record: Modifies columns on the primary triggering record, or on any related record accessible via an N:1 lookup relationship (e.g., updating the parent Account from a Contact event).
• Assign Record: Reassigns ownership of the primary record or a related parent record to a specified user or team.
• Send Email: Generates and sends an email message using a pre-defined Email Template or dynamically constructed body text with slug values.
• Change Status: Transitions the record to a specific state (e.g., Deactivating an Account, setting an Invoice to Paid).
• Start Child Workflow: Calls another activated workflow marked with the property "As a child process". This promotes modular architecture, allowing complex logic to be partitioned into reusable components.
• Stop Workflow:
  • Status: Succeeded: Explicitly terminates the workflow run successfully.
  • Status: Canceled: Terminates the workflow in a faulted state. In a Real-Time Workflow, selecting Canceled prompts the designer to enter a Custom Error Message. When triggered, Dataverse immediately rolls back the database transaction and displays the custom error text directly to the user in a modal business process error dialog.

[!IMPORTANT] Synchronous Validation & Error Display: Setting a Real-Time Workflow to execute in the Pre-operation stage with a Stop workflow with status: Canceled action is the standard declarative method in classic Dataverse to block an invalid save and surface a custom error message to the end user without code.

---

4. Real-Time Workflows vs. Power Automate Cloud Flows

Understanding when to build a Modern Cloud Flow versus when a Classic Real-Time Workflow is required is a core competency tested on the PL-200 exam.

[!TIP] Exam Architecture Rule: Default to Power Automate Cloud Flows for all modern background automations, approvals, integrations, and scheduled tasks. Choose Classic Real-Time Workflows (or Low-Code Plug-ins) ONLY when the requirement demands immediate synchronous execution, atomic database rollback, or blocking form saves with custom error dialogs.