What the Dynamics 365 Plug-in Execution Pipeline Means for Your Customizations
You need to know how the plugin execution pipeline works in Dynamics 365 and CRM. This pipeline picks when your custom logic will run. In Microsoft Dynamics CRM, when your code runs can help protect data. It also helps follow business rules. If you learn this well, you can make strong and reliable customizations for Dynamics 365 and Dataverse. Planning the pipeline stages and order helps keep your CRM solutions fast and correct. You should always think about ways to debug to keep your Microsoft Dynamics projects working well.
Key Takeaways
The Dynamics 365 plugin execution pipeline decides when your custom code runs. This helps keep your data safe. It also makes sure business rules are followed.
The pipeline has important steps. These are pre-validation, pre-operation, main operation, post-operation, and post-validation. Each step has a special job in handling data.
Plugin depth means how many times a plugin runs in one action. If the depth is high, it can cause loops. Loops can slow down or crash your system.
Use synchronous plugins for tasks that must finish right away. These tasks need to finish before users can keep working. Use asynchronous plugins for jobs that run in the background. These jobs do not stop users from working.
Follow best practices to keep plugins fast, simple, and safe. This makes your Dynamics 365 customizations work well and stay reliable.
Plugin Execution Pipeline in Dynamics 365
What Is the Plugin Execution Pipeline?
When you change Dynamics 365 or Dataverse, you use the plugin execution pipeline. This pipeline decides how your plugin code runs after something happens, like create, update, or delete in CRM. The pipeline is part of the organization service in Microsoft Dynamics. It lets you pick when your business logic should run during a transaction. The plugin event execution pipeline has different stages. Each stage lets you check data, change values, or start other actions.
Here is a table that lists the main stages of the pipeline and what they do:
You can also look at this chart to see the stages:
Why It Matters for Customizations
It is important to know the plugin event execution pipeline to make good customizations in Dynamics 365 CRM. The pipeline helps you control when your code runs. For example, you can fill in fields automatically when you create or update records. You can make sure business rules and field dependencies are followed. You can connect CRM with other apps using Dataverse. You can handle plugin chains and stop problems like transaction rollbacks or security mistakes. You can use logs to track plugin execution and make your design better.
Filling in fields when you create or update records.
Doing extra checks for business rules.
Sharing data with other apps.
Handling plugin triggers for things like finishing appointments.
Managing execution context and filtering attributes.
Execution Context and Events
When something happens in Dynamics 365 or Dataverse, the organization service sends details to the plugin. The execution context gives your plugin important information. You get things like BusinessUnitId, CorrelationId, Depth, and InitiatingUserId. You also get InputParameters and OutputParameters, which let you see and change data. PreEntityImages and PostEntityImages show what the entity looked like before and after the event. The plugin event execution pipeline works with different event types. For create and update events, you get the whole record. For delete events, you only get the ID and logical name. You must handle each event type the right way to stop errors and keep your CRM data safe.
Pipeline Stages and Order
The plugin execution pipeline in Dynamics 365 and Dataverse has different steps. Each step decides when plugins run and how they work with data. You need to know these steps to make your customizations work well and keep your business rules safe.
Here is a table that lists the five main steps, when they happen, and what they do:
Pre-validation Stage
The pre-validation stage lets you check data before the main system starts. This step happens outside the database and before security checks. Plugins here help you check data, follow business rules, and make sure things are ready. You can stop an event early if the data is wrong. For example, you can look for duplicate records before making a new one. If there is an error here, it does not undo other plugin work.
Tip: Use the pre-validation stage to find problems early and save time later.
Pre-operation Stage
The pre-operation stage happens right before the main dataverse step and inside the database. Plugins here let you change data before the main step. You can set default values, update other records, or get data ready for the next step. If a plugin has an error here, everything rolls back. This step comes after pre-validation, so all checks should be done before you change anything.
You can use this step to:
Set default values for new records.
Update other records before saving.
Get data ready for hard business rules.
Changing data in pre-operation changes what later steps see. If you change a field here, plugins in post-operation will see the new value.
Main Operation Stage
The main operation stage is the main system step. The system does the real dataverse job, like making, changing, or deleting a record. You cannot add plugins at this step. The main operation is between pre-operation and post-operation. Plugins work with this step by running before or after it.
The main operation stage is the main step.
Plugins run in pre-operation before the main step.
Plugins run in post-operation after the main step.
Post-operation Stage
The post-operation stage happens after the main dataverse step and inside the database if it is synchronous. Plugins here can do extra work, checks, or updates after the main job is done. You can use this step to send messages, update other records, or connect to other apps. If a plugin has an error in synchronous post-operation, everything rolls back. Asynchronous plugins run after the main job is finished.
Common uses for post-operation plugins:
Show in-app messages for users.
Update other records after the main event.
Post-validation Stage
The post-validation stage comes after all other steps and outside the database. This step helps keep data correct and safe. Dataverse uses this step for last checks, like checking files, making sure all info is there, and keeping track of versions. You cannot change files directly after this step. You must add new versions, which keeps updates safe and easy to follow.
The post-validation stage helps with:
Checking if all info is there.
Keeping track of versions.
Reviewing data before it goes live.
Extra storage and checks for data safety.
Order of Operations and Impact
The order of steps in the plugin pipeline changes how plugins work with data and react to events. If a plugin fails early, later steps might not run. For example, if a pre-validation plugin stops an event, the next plugins do not run. Changing data in pre-operation changes what post-operation plugins see. You need to plan your plugins so they do not cause problems and your dataverse works well.
Note: Always test your plugins in each step to make sure they work together and handle mistakes the right way.
Plugins in Dataverse: Depth and Chaining
Understanding Plugin Depth
Plugin depth tells you how many times a plugin runs in one action. You can see this number in the execution context as context.Depth. When a plugin starts in CRM, the depth is 1. If your plugin makes another event that runs the same plugin, the depth goes up to 2. This happens if a plugin updates a record and that update triggers the plugin again. Depth helps you know if plugins are running inside each other or in a loop. Microsoft sets a top depth of 8 to stop endless loops and keep the system safe.
Tip: Always look at the depth value in your plugin code. If the depth is high, you might have a loop problem.
Chaining Plugins and Order of Execution
Chaining plugins means you link more than one plugin to run one after another in CRM. The order they run depends on the priority number you give each plugin. Plugins with lower numbers run before others. If two plugins have the same number, CRM runs them in the order you added them. You can use negative, zero, or positive numbers to set the order. Microsoft lets you set plugins at different levels, like default or group, to help organize your logic.
Chaining plugins lets you make complex business rules in CRM. You choose which plugin runs first and how data moves between them.
Debugging Complex Plugin Chains
Debugging plugin chains in Microsoft Dynamics CRM can be hard. You need to know which plugin runs and when it runs. The Plugin Profiler helps you record plugin runs. You install the profiler, pick the plugin step, and start recording. After you trigger the event, you use Visual Studio to attach the debugger and set breakpoints. The Plugin Registration Tool lets you pick the saved profile and start debugging. You can check each plugin and see how data changes at every step.
Note: Always test your plugins in dataverse by doing the registered action. This makes sure your plugins work and helps you find mistakes early.
Too much plugin depth or loops can cause problems:
The system gets slow.
Endless loops crash the system.
Depth limit errors stop plugins from running.
Debugging becomes more difficult.
You should use flags or shared variables to stop loops. Move hard logic to outside services if you need to. This helps your CRM work well.
Synchronous vs. Asynchronous Execution
When you change Dynamics 365, you pick how plugins run. You can pick synchronous or asynchronous execution. Each one changes how the system works. It also changes what users see and feel.
Synchronous Plugins
Synchronous plugins run right away when something happens. The system waits for the plugin to finish. You see what happens right away. This is good for checking fields or business rules. It is also good for updating records before saving. Synchronous plugins stop users until they are done. If something goes wrong, the system undoes all changes. This keeps your data safe and results clear.
Tip: Use synchronous plugins if you need instant feedback or must finish tasks before users move on.
Here is a table with main features:
Asynchronous Plugins
Asynchronous plugins run in the background. The system does not wait for them to finish. Users can keep working while the plugin runs. This is best for sending alerts or working with other systems. It is also good for big data jobs. Asynchronous plugins help the system run faster. They do not stop users. If something fails, the system tries again. You might see some updates before all jobs finish.
Common uses for asynchronous plugins:
Sending emails or alerts
Updating other systems
Working with lots of data
Choosing the Right Mode
Pick the mode that fits your needs. Synchronous is best for jobs that need to finish right away and keep data safe. Asynchronous is good for background jobs and big data work. Many systems use both types. Use synchronous for important jobs. Use asynchronous for jobs that need to grow. Always test your setup to make sure it works for you.
Practical Examples and Best Practices
Pre-operation vs. Post-operation Code Snippets
Plugins can run at different times to control your business logic in Dynamics 365 or dataverse. Here are two easy code examples. One is for pre-operation, and one is for post-operation.
Pre-operation Plugin Example
This plugin puts a default value before the main job starts.
public void Execute(IServiceProvider serviceProvider)
{
var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
var entity = (Entity)context.InputParameters["Target"];
if (!entity.Attributes.Contains("new_status"))
{
entity["new_status"] = "Pending";
}
}
Post-operation Plugin Example
This plugin sends an email after the main job is done.
public void Execute(IServiceProvider serviceProvider)
{
var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
if (context.MessageName == "Create")
{
// Logic to send an email notification
}
}
Tip: Change data in pre-operation before saving. Use post-operation to do things after saving.
Best Practices for Plugin Development
When you make plugins, you want them to be fast and safe. Here are some best ways to do that:
Only get the data you really need.
Do not keep data between plugin runs.
Use system-made GUIDs for better speed.
Always use the SDK to change data.
Pick synchronous or asynchronous based on your needs.
Run plugins with the lowest user rights needed.
Only use impersonation if you must.
Register post-operation plugins after the main job for security.
Do not put slow code in synchronous plugins.
Use managed code to help stop security problems.
Common Pitfalls to Avoid
Some mistakes can cause trouble in the pipeline. You should know what these are:
Note: Sometimes, using workflows or Power Automate is better than a plugin, depending on what you need.
You now understand what the plugin execution pipeline does for your customizations in Dynamics 365 and CRM. Knowing about each stage helps you pick where your logic should go. This stops unwanted rollbacks and keeps your CRM working well. Using tools like Plugin Registration Tool or XRM Toolbox makes debugging and managing plugins easier. Keep learning from resources and community tools to get better at advanced plugin development.
FAQ
What is plugin depth in Dynamics 365?
Plugin depth shows how many times a plugin runs during one action. You can check the depth in your plugin code. High depth often means your plugins call each other in a loop.
What happens if a plugin fails in the pre-operation stage?
If a plugin fails in pre-operation, Dynamics 365 cancels the whole transaction. The system rolls back all changes. You keep your data safe and avoid partial updates.
What is the difference between synchronous and asynchronous plugins?
Synchronous plugins run right away and make users wait. Asynchronous plugins run in the background. Users do not wait. You use synchronous for quick checks and asynchronous for background tasks.
What tools help you debug plugin execution in Dynamics 365?
You can use the Plugin Profiler and Plugin Registration Tool. These tools let you record plugin runs, set breakpoints, and step through your code. You find errors faster and fix problems with more confidence.