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

  1. IPluginExecutionContext.Stage Property (Microsoft.Xrm.Sdk) Microsoft · · Primary, current docs 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.
  2. Event Framework in Microsoft Dataverse Microsoft · · Primary, current docs 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.
  3. Microsoft Dynamics CRM 2011 SDK (compiled help, CrmSdk2011.chm) Microsoft · Primary, archived 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.