Depth vs ParentContext vs CorrelationId

Three properties on the plug-in execution context that sound interchangeable and are not. Microsoft says not to build logic on one of them at all.

Answer first

Depth tells you how deep in a chain of nested plug-in and workflow executions you are. ParentContext gives you the execution context of the operation that caused yours, when the platform generated your request itself. CorrelationId is a GUID the platform uses to spot loops.

If you want to know why your plug-in is running, ParentContext is the documented way to find out. Do not use Depth for that: Microsoft’s current reference says outright not to take a dependency on it.

Depth

Depth is the current depth of execution in the call stack. Each time a running plug-in or workflow sends a request that triggers another plug-in or workflow, the new execution’s Depth goes up by one.

The platform uses it to stop infinite loops. If Depth reaches its maximum within the configured time limit, the platform treats the chain as a loop and aborts further plug-in or workflow execution. The defaults are a maximum depth of 8 within one hour, and both are configurable by an administrator. On a deployment you administer yourself, the current reference names the setting as WorkflowSettings.MaxDepth, changed with the Set-CrmSetting PowerShell command.

The warning that matters is in the current reference, not in the 2011 one:

Do not take any dependency on the IExecutionContext.Depth property in your code.

The reason given is that the same operation can arrive by a different code path at any time, because of configuration changes outside your control, and logic that depends on a particular Depth value breaks when it does. A check like if (context.Depth > 1) return; is exactly that: it assumes the shape of the chain above you stays the same.

ParentContext

ParentContext is the execution context of the parent pipeline operation. It may be populated for a plug-in registered in stage 20 or 40 when a Create, Update, Delete or RetrieveExchangeRate request goes through the pipeline.

It exists because some requests make the platform generate another request internally, which runs its own pipeline. The documented example is an AssignRequest, which produces an internal UpdateRequest. A plug-in registered in stage 20 or 40 on that update sees ParentContext set to the execution context of the original assign.

So an update plug-in that fires unexpectedly when a record is assigned is not misbehaving: the assign really did cause an update, and ParentContext is where that is visible.

CorrelationId

CorrelationId is a GUID for tracking plug-in or custom workflow activity execution. Both the 2011 and the current reference say the same two things about it: the platform uses it for infinite loop prevention, and in most cases you can ignore it.

Neither reference describes it as an identifier for your own logging or tracing, so this page does not either.

Which versions this covers

The remarks for all three properties are word for word the same in the 2011 SDK and the current reference, apart from the Depth warning, which is only in the current one. That strongly suggests nothing changed in between, but the SDKs for 2013 through 9.x have not been checked here, so the page only claims the two versions it has actually been read against.

Sources

  1. IExecutionContext.Depth Property (Microsoft.Xrm.Sdk) Microsoft · · Primary, current docs Current SDK reference. Carries the 2011 wording on loop prevention, the maximum depth of 8 within one hour, and an explicit instruction not to take a dependency on Depth in code.
  2. IExecutionContext.CorrelationId Property (Microsoft.Xrm.Sdk) Microsoft · · Primary, current docs Current SDK reference. Same remarks as 2011: used by the platform for infinite loop prevention, and in most cases can be ignored.
  3. IPluginExecutionContext.ParentContext Property (Microsoft.Xrm.Sdk) Microsoft · · Primary, current docs Current SDK reference. Same remarks as 2011: populated for stage 20 or 40 on Create, Update, Delete or RetrieveExchangeRate when the platform internally generates another request, with Assign generating Update as the example.
  4. 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.