Event pipeline stages: 10, 20, 40 and 50
Which stage runs when, which stages are guaranteed to be inside the database transaction, why pre-validation runs before security checks, and why stage 50 is still listed.
Answer first
Four stage numbers matter when you register a plug-in: 10 pre-validation, 20 pre-operation, 40 post-operation, and 50, a deprecated post-operation stage. Stages 20 and 40 are guaranteed to be inside the database transaction; 10 and 50 are not. Stage 30 is the platform’s own operation.
Sources: the Event Execution Pipeline topic in the CRM 2011 SDK, and the
current IPluginExecutionContext.Stage reference, which still lists 10, 20,
40 and 50, with 50 marked deprecated.
To see one registration explained, with its images and what an exception rolls back, use the plug-in stage and mode explorer.
The stages
| Stage | Number | Inside the transaction? | Worth knowing |
|---|---|---|---|
| Pre-validation | 10 | Not guaranteed | Runs before security checks |
| Pre-operation | 20 | Yes | Where to change values on the record in the message |
| Main operation | 30 | Yes | The platform’s own create, update, delete and so on |
| Post-operation | 40 | Yes, when synchronous | Asynchronous steps can be registered here |
| Post-operation (deprecated) | 50 | Not guaranteed | In 2011, for CRM 4.0-based plug-ins only |
The 2011 SDK puts the transaction rule in one sentence: stages 20 and 40 are guaranteed to be part of the database transaction, while stages 10 and 50 may be.
Pre-validation runs before security checks
Sources: both. The 2011 SDK and current Dataverse documentation say the same thing.
Pre-validation happens before the platform checks that the calling user has permission to perform the operation. Code in stage 10 cannot assume the operation it is looking at will be allowed.
Current documentation adds two points. For the initial operation, pre-validation is the place to cancel before the database transaction starts. And operations triggered by extensions registered in other stages still pass through pre-validation, but by then they are inside the calling extension’s transaction.
Stage 30
Sources: both, and they differ.
In CRM 2011, no custom plug-in can be registered in stage 30; it is for internal use only. Current Dataverse documentation keeps it internal, with two exceptions: custom APIs and custom virtual table data providers.
Where to change data, and where not to
Source: current Dataverse documentation.
- Change values on the record in the message in pre-operation.
- Avoid cancelling in pre-operation. Cancelling there rolls back the transaction and is expensive; detect the condition in pre-validation instead.
- Avoid changing the record in the message in post-operation. Doing so triggers a new Update event.
Exceptions roll back the transaction
Source: current Dataverse documentation.
An exception thrown by code in any synchronous stage inside the database
transaction rolls back the entire transaction. To cancel an operation on
purpose, check for the condition in pre-validation and throw an
InvalidPluginExecutionException with a message explaining why.
Asynchronous steps
Sources: both, with different detail.
The 2011 SDK describes synchronous plug-ins running immediately and asynchronous ones being queued and run later by the asynchronous service. Current documentation is more specific: asynchronous execution is available when registering for post-operation, and those steps run outside the database transaction.
Order within a stage
Sources: both.
Several plug-ins registered for the same message and stage run in a defined
order. In 2011 that order is the rank set at registration; the current
reference names the same thing as SdkMessageProcessingStep.Rank, shown as
Execution Order when registering.
Update can run twice
Source: current Dataverse documentation.
In certain cases the platform calls plug-ins and workflows registered for Update twice. Microsoft documents those cases separately, under the behaviour of specialized update operations, and this page does not summarise them.
Which versions this covers
Read against the CRM 2011 SDK and current Dataverse documentation only. The stage numbers, the transaction rules and the security-check timing agree between the two. Where a point above comes from current documentation alone, it is not claimed for 2011, and the SDKs for 2013 through 9.x have not been checked here.
Sources
- IPluginExecutionContext.Stage Property (Microsoft.Xrm.Sdk) Current SDK reference. Valid stage values are 10 (pre-validation), 20 (pre-operation), 40 (post-operation) and 50 (post-operation, deprecated); plug-ins within a stage are ordered by SdkMessageProcessingStep.Rank.
- Event Framework in Microsoft Dataverse Current Dataverse documentation. The four pipeline stages and their transaction rules, cancelling in PreValidation, rollback on exceptions, asynchronous steps in PostOperation, Execution Order, and the note that Update can run twice.
- Microsoft Dynamics CRM 2011 SDK (compiled help, CrmSdk2011.chm) Private archive: CRM-SDK-Rescue/2011-SDK_from_desk/SDK/CrmSdk2011.chm Microsoft's own SDK help for the 2011 release, from an owner-held copy. Static reading only; the package is never executed and is not part of this repository. Quote sparingly and cite; do not republish.