Study guide
5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages
Microsoft Power Platform Developer Associate PL-400
Track your progress as you read
Finished sections get a check mark.
1 Introduction, Exam Overview & Developer Toolchain
0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow
2 Create a Technical Design
1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations
3 Build Power Platform Solutions
2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools
4 Implement Power Apps Improvements
3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance
5 Extend the User Experience
4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component
6 Extend the Platform: Dataverse Plug-ins & Custom APIs
5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events
7 Extend the Platform: Custom Connectors
6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation
8 Extend the Platform: Platform APIs & Azure Functions
7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities
9 Extend the Platform: Power Automate Cloud Flows
8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals
10 Develop Integrations
9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message
11 Exam Readiness & Practice
10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan
5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages
Key Takeaways Explain This Topic AI
A plug-in is a .NET class library that implements IPlugin and runs inside the Dataverse event execution pipeline in response to a message such as Create or Update.
The pipeline has four stages: Pre-validation (stage 10), Pre-operation (stage 20), Main operation (stage 30, reserved for the platform), and Post-operation (stage 40).
Pre-validation runs outside the database transaction and before the security privilege check; Pre-operation and Post-operation run inside the transaction.
Only Post-operation (stage 40) plug-ins can run asynchronously; Pre-validation and Pre-operation must run synchronously because they gate the core operation.
Choosing the correct stage and mode is a technical-design decision as much as a coding decision -- it determines whether your logic can block bad data, see committed changes, or run without slowing down the user.
Last updated: July 2026
Every create, update, delete, or retrieve against Dataverse -- whether it originates from a model-driven app form save, a Power Automate flow, the Web API, or another plug-in -- passes through the same processing pipeline before Dataverse commits it to the database. Understanding that pipeline, and where a plug-in sits inside it, is the foundation for everything else in Domain 5 of PL-400: business logic in plug-ins, custom APIs, business events, even integration patterns all build on this model.
What a Plug-in Is
A plug-in is a class in a compiled .NET assembly (a DLL) that implements the SDK's IPlugin interface: public interface IPlugin
- {
- void Execute(IServiceProvider serviceProvider);
- }
You register that assembly with Dataverse (via the Plug-in Registration Tool -- covered in 5.4), and Dataverse invokes Execute whenever a matching message occurs against a matching table. A message is the SDK name for an operation: Create , Update , Delete , Retrieve , RetrieveMultiple , Assign , SetState , Associate , Disassociate , and custom messages you define yourself (5.5). Every plug-in step you register is a subscription to one message, on one table (or all tables, for a handful of messages), at one pipeline stage.
The Event Execution Pipeline
Dataverse processes every message through the same ordered pipeline of stages, whether or not any custom plug-in is registered on it:
- Stage number Stage name Runs inside DB transaction? Who can register here
- 10 Pre-validation No Custom plug-ins (sync only)
- 20 Pre-operation Yes Custom plug-ins (sync only)
- 30 Main operation Yes Platform core only (not partner code)
- 40 Post-operation Yes if sync, no if async Custom plug-ins (sync or async)
Pre-validation (10) is the earliest point a plug-in can intercept a request. It runs before the platform checks the calling user's security privileges and before the database transaction opens. This makes it the right stage for logic that should reject bad input as cheaply as possible, before Dataverse spends any effort on the request -- but it also means a pre-validation plug-in cannot assume the user is authorized to perform the operation, and it cannot see data written by other plug-ins in the same transaction, because no transaction exists yet.
Pre-operation (20) runs after the privilege check but before Dataverse's core platform logic executes. The database transaction is already open, so a pre-operation plug-in can modify the incoming data (through InputParameters , covered in 5.2) and those changes flow into the main operation as if the caller had sent them -- this is the standard stage for defaulting or correcting field values before they're saved.
Main operation (30) is where Dataverse's own platform code performs the actual database write. Partner and ISV plug-ins cannot register here; it's reserved for Microsoft's internal system operations. You'll see it referenced on the exam mainly so you can rule it out as a registration option.
Post-operation (40) runs after the core operation completes. This is the only stage available for asynchronous execution, and it's the stage most business logic uses -- because by the time a post-operation plug-in runs, the record has already been created or updated (with a real GUID, for Create ), and any other synchronous plug-ins on earlier stages have already run. If the step is registered as synchronous, it's still inside the same database transaction as the triggering operation: throwing an exception here rolls back everything, including the main operation.
Synchronous vs. Asynchronous Execution
Synchronous plug-ins run in-line with the user's request, inside the same transaction. The caller waits for them to finish, and the caller's operation fails (with the plug-in's error shown to the user) if the plug-in throws. Synchronous plug-ins are only valid at stages 10, 20, and 40.
Asynchronous plug-ins are queued as a system job and executed later by a background service. The caller's request returns immediately without waiting. Asynchronous execution is only available at stage 40 (post-operation) -- it wouldn't make sense at pre-validation or pre-operation, since those stages exist specifically to influence or block an operation that hasn't happened yet, and an async job can't do that after the fact. Use async for logic that's slow (calling an external API), non-critical to the immediate transaction (sending a notification), or that doesn't need to block the user from seeing their save succeed.
Picking the Right Stage: A Design Decision
The PL-400 exam frequently tests this as a scenario question rather than a memorization question: given a requirement ("block the save if X," "recalculate a value after the record commits," "call a slow external service without delaying the user"), you're expected to name the correct stage and mode. As a rule of thumb: validation and blocking logic belongs in pre-validation or pre-operation (synchronous); logic that depends on the committed record, or that touches other tables/systems, belongs in post-operation (synchronous if it must still block a related process, asynchronous if it doesn't). Later sections build directly on this: 5.2 covers how a plug-in reads and writes data once it's executing inside a chosen stage, and 5.3 covers how pre- and post-images let a plug-in see data from before and after the core operation.