The Plug-in Pipeline: How Dataverse Processes Events

The pipeline that powers Dataverse

The four pipeline stages

Stage	When It Runs	Transaction?	Can Cancel Operation?	Best For
Pre-validation (Stage 10)	Before security checks	No — outside transaction	Yes	Light validation, early rejection
Pre-operation (Stage 20)	After security, before DB write	Yes — inside transaction	Yes	Modify data before save, complex validation
Main operation (Stage 30)	The actual database operation	Yes — the core transaction	N/A (system only)	Cannot register plug-ins here
Post-operation (Stage 40)	After the DB write	Yes — still inside transaction	Yes (rolls back entire transaction)	Create related records, trigger integrations

Synchronous vs asynchronous execution

Mode	Runs When	User Experience	Use For
Synchronous	Immediately, blocks the operation	User waits	Validation, data modification, must-run logic
Asynchronous	After the transaction commits, in background	User continues working	Notifications, logging, non-critical processing

💡 Exam tip: The stage selection pattern

The exam will describe a scenario and ask which stage is correct. Use this decision tree:

1. Need to reject invalid data before security checks run? → Pre-validation
2. Need to modify or enrich data before it is saved? → Pre-operation
3. Need to create related records or trigger integrations after save? → Post-operation (sync)
4. Need to send notifications or log events without blocking the user? → Post-operation (async)

Red flag: If an answer says “register on the Main operation stage” — it is always wrong. You cannot register plug-ins on Stage 30.

The execution context

Every plug-in receives an IPluginExecutionContext that tells you everything about the current operation:

public class ShipmentValidator : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        // Get the execution context
        IPluginExecutionContext context = (IPluginExecutionContext)
            serviceProvider.GetService(typeof(IPluginExecutionContext));
        
        // What operation triggered this plug-in?
        string messageName = context.MessageName;  // "Create", "Update", "Delete"
        
        // What entity is being affected?
        string entityName = context.PrimaryEntityName;  // "shipment"
        
        // What stage are we in?
        int stage = context.Stage;  // 10, 20, 30, or 40
        
        // Who triggered the operation?
        Guid userId = context.UserId;           // The calling user
        Guid initiatingUserId = context.InitiatingUserId;  // Original user (even through impersonation)
        
        // What data is being sent? (for Create/Update)
        Entity target = (Entity)context.InputParameters["Target"];
        string destination = target.GetAttributeValue<string>("destination");
        
        // What depth are we at? (prevents infinite loops)
        int depth = context.Depth;  // 1 = original, 2+ = triggered by another plug-in
    }
}

Key context properties

Property	What It Tells You
MessageName	The operation: Create, Update, Delete, Retrieve, etc.
PrimaryEntityName	The table being affected
Stage	Which pipeline stage (10, 20, 30, 40)
UserId	The user executing the operation (may be impersonated)
InitiatingUserId	The original user who started the chain
InputParameters[“Target”]	The record being created/updated (Entity object)
Depth	Recursion depth (check to prevent infinite loops)
PreEntityImages	Snapshot of the record BEFORE the operation
PostEntityImages	Snapshot of the record AFTER the operation

Pre Images and Post Images

Images are snapshots of a record at specific points in the pipeline.

Images give your plug-in a before-and-after view — register only the fields you need

Feature	Pre Image	Post Image
Shows	Record values BEFORE the operation	Record values AFTER the operation
Available in	Pre-validation, Pre-operation, Post-operation	Post-operation only
Useful for	Comparing old vs new values, checking what changed	Verifying final state, accessing calculated fields
Contains	Fields you registered for in the image definition	Fields you registered for in the image definition
On Create	Not available (no previous state)	Available in post-operation
On Delete	Available (record exists before delete)	Not available (record is gone)

Using images to detect changes

// In a Post-operation Update plug-in
Entity preImage = context.PreEntityImages["preImage"];
Entity postImage = context.PostEntityImages["postImage"];

// statuscode is an OptionSetValue, not a string
int oldStatus = preImage.GetAttributeValue<OptionSetValue>("statuscode")?.Value ?? -1;
int newStatus = postImage.GetAttributeValue<OptionSetValue>("statuscode")?.Value ?? -1;

if (oldStatus != newStatus)
{
    // Status changed — trigger notification
    tracingService.Trace($"Status changed from {oldStatus} to {newStatus}");
}

💡 Scenario: Kai uses images to track shipment changes

Kai registers a Post-operation Update plug-in on the Shipment table at LogiFlow. He configures:

• Pre Image: includes status, destination, priority fields
• Post Image: includes status, destination, priority fields

When a shipment’s status changes from “In Transit” to “Delivered”, the plug-in compares the pre and post images, sees the status change, and creates a Delivery Confirmation record with the delivery timestamp.

Why images instead of Target? The Target entity in an Update only contains the fields that were actually changed. If Kai needs to check the destination (which was not changed in this update), it would not be in Target — but it IS in the Pre Image.

Question

What are the four stages of the Dataverse event execution pipeline?

Click or press Enter to reveal answer

Answer

Pre-validation (Stage 10, outside transaction), Pre-operation (Stage 20, inside transaction), Main operation (Stage 30, the database write — no plug-ins allowed), Post-operation (Stage 40, inside transaction). Plug-ins can register on stages 10, 20, and 40.

Click to flip back

Question

What is the difference between context.UserId and context.InitiatingUserId?

Click or press Enter to reveal answer

Answer

UserId is the identity executing the current operation (may be impersonated by a plug-in or flow). InitiatingUserId is the original user who started the entire operation chain. Use InitiatingUserId when you need to know who really triggered the action, regardless of impersonation.

Click to flip back

Question

Why is context.Depth important in plug-in development?

Click or press Enter to reveal answer

Answer

Depth tracks recursion — if your plug-in triggers another operation that triggers the same plug-in, Depth increments. Check Depth to prevent infinite loops: if (context.Depth > 1) return; Without this check, a plug-in that updates its own entity can loop forever.

Click to flip back

Question

Why would you use a Pre Image instead of reading the Target entity?

Click or press Enter to reveal answer

Answer

The Target entity only contains fields that were actually modified in the current operation. If you need to read a field that was NOT changed (e.g., checking the record's owner during a status update), it will not be in Target. Pre Images contain whatever fields you registered for, regardless of whether they changed.

Click to flip back

Knowledge Check

A developer needs to validate that a Shipment record's weight does not exceed 1000kg BEFORE security checks run. If the weight exceeds the limit, the operation should be cancelled immediately. Which pipeline stage should the plug-in be registered on?

APre-validation (Stage 10)BPre-operation (Stage 20)CPost-operation (Stage 40) synchronousDPost-operation (Stage 40) asynchronous

Check Answer

Knowledge Check

A plug-in registered on Post-operation Update needs to check whether the Priority field changed. The developer reads context.InputParameters['Target'] but Priority is not in the Target entity. Why?

AThe Target entity is empty on Update operationsBThe Priority field was not modified in this update — Target only contains changed fieldsCPost-operation plug-ins do not have access to InputParametersDThe Priority field is a system field that cannot be read by plug-ins

Check Answer

Next up: Writing Plug-ins — implementing business logic with the Organisation Service, performance optimisation, and plug-in registration.