In this guide, we\u2019ll break down the prevalidation stage in Dynamics CRM, explain how it differs from other stages, and show how to use it. All of these will help make your Dynamics 365 plugin development smoother, faster, and far more reliable. <\/p>\n\n\n\n
Here we go!<\/p>\n\n\n\n
Key Takeaways<\/strong><\/p>\n\n\n\n Every time a user creates, updates, or deletes a record in Microsoft Dynamics 365, that operation passes through a defined plugin execution pipeline. This pipeline determines when and how custom business logic executes. Knowing exactly where your plugin fits in this flow is essential for building a reliable and scalable Dynamics 365 solution<\/a>.<\/p>\n\n\n\n Each stage has a specific purpose and impact on how data moves through the system. Let\u2019s break them down one by one.<\/p>\n\n\n\n The prevalidation stage in Dynamics CRM executes before the platform\u2019s core operations and before any security or database validation occurs. Since it runs outside the transaction, this stage gives developers the earliest chance to act on incoming data.<\/p>\n\n\n\n You can inspect input parameters, run quick data checks, or stop invalid requests before they even reach the system. For example, if an import contains duplicate records or missing mandatory fields, a prevalidation plugin in Dynamics 365 can reject the operation instantly, which saves hours of cleanup later.<\/p>\n\n\n\n When to use it:<\/p>\n\n\n\n <\/p>\n <\/p>\n \t\t\t<\/div>\n \t\t\t \t\t<\/div>\n \t<\/section>\n \n\n\n\n The pre-operation stage runs after security checks but before the database transaction commits. It\u2019s part of the same transaction, meaning any exceptions you throw here will roll back the entire operation.<\/p>\n\n\n\n This stage is perfect for adjusting field values, applying conditional logic, or ensuring related data is ready before saving. For instance, you could automatically populate fields, calculate totals, or update related entities before the record is persisted.<\/p>\n\n\n\n When to use it:<\/p>\n\n\n\n Be careful with performance-heavy operations here; anything that slows execution delays the transaction itself.<\/p>\n\n\n\n <\/p>\n <\/p>\n<\/div>\n<\/div>\n<\/section>\n\n\n\n The main operation is where Dynamics 365 performs its internal logic: creating, updating, or deleting the actual record. Developers can\u2019t register plugins in this stage, but understanding it helps determine when your pre- and post-operation logic executes relative to the system\u2019s native actions.<\/p>\n\n\n\n Essentially, this is the moment when the data change happens. Your pre-operation logic prepares for it, and your post-operation logic reacts to it.<\/p>\n\n\n \t <\/p>\n <\/p>\n \t\t\t<\/div>\n \t\t\t \t\t\t\t The post-operation stage fires after the record has been committed to the database. Depending on whether the plugin is synchronous or asynchronous, this can happen either within the same transaction or later as a background process.<\/p>\n\n\n\n This is the best place for actions that depend on finalized data, such as notifications, logging, or updating related records. Now, because the data exists in the database, your plugin can safely access the record\u2019s GUID and other system-generated fields.<\/p>\n\n\n\n When to use it:<\/p>\n\n\n\n <\/p>\n <\/p>\n \t\t\t<\/div>\n \t\t\t \t\t<\/div>\n \t<\/section>\n \n\n\n\n Prevalidation plugins in Dynamics 365 are executed before the main transaction pipeline begins. They run even before the platform performs security checks or starts database-level operations, giving developers an early interception point to validate or control incoming data.<\/p>\n\n\n\n These plugins operate outside the transaction scope, so they allow developers to stop invalid operations before they affect system performance or data integrity.<\/p>\n\n\n\n In practical terms, a prevalidation plugin serves as a gatekeeper.<\/p>\n\n\n\n When a record is created, updated, or deleted, the plugin checks whether the data meets predefined business rules before allowing the process to continue. This is especially useful for scenarios that require early data verification, such as checking an email field format, validating mandatory attributes, or preventing duplicate records across multiple entities.<\/p>\n\n\n\n For example, when users create a new contact with an incorrectly formatted email address, a prevalidation plugin can block the request immediately, long before any database write occurs. Similarly, in account creation workflows, developers can use this stage to verify if a record with the same tax ID already exists. This avoids duplicates that could later cause compliance or reporting issues.<\/p>\n\n\n\n Think of the prevalidation stage in Dynamics CRM as your first line of defense\u2014it stops bad data before the system even starts processing it. Let\u2019s look at when you should use it.<\/p>\n\n\n\n Bulk imports can go wrong fast. When users upload hundreds or thousands of records, you want to catch issues before the system wastes resources on invalid data. Say you’re importing contacts, and each one needs to link to an active account. A prevalidation plugin in Dynamics 365 <\/em><\/strong>checks this before anything gets written:<\/p>\n\n\n\n The beauty here is efficiency. If 500 contacts reference dead accounts, they fail immediately. No transactions started, no resources wasted. The user gets clear feedback about what went wrong.<\/p>\n\n\n\n Using system context (CreateOrganizationService(null)<\/strong>) enables the plugin to check accounts regardless of who’s doing the import. The rule applies to everyone, so the plugin enforces it universally.<\/p>\n\n\n\n Sometimes your business rules go beyond what security roles can handle. You might need to block actions based on record status, not user permissions. Here’s a common one: preventing users from deleting active opportunities. Security roles control who can delete opportunities, but they can’t check whether those opportunities are still open. Prevalidation plugins in Dynamics 365 fill that gap:<\/p>\n\n\n\n This runs before security checks and before any database transaction. The operation stops immediately with a clear message.<\/p>\n\n\n\n The same pattern works for update restrictions. If approved, invoices should become read-only; a prevalidation plugin enforces that:<\/p>\n\n\n\n These rules protect your data across the board\u2014API calls, manual updates, workflows, everything.<\/p>\n\n\n\n Data validation in Dynamics 365 CRM often means checking relationships between records. You need to make sure parent-child relationships make sense before committing changes.<\/p>\n\n\n\n Here\u2019s a manufacturing scenario: work orders must link to locations with available capacity. The prevalidation plugin checks this:<\/p>\n\n\n\n This validation happens before any transaction starts. During bulk work order creation, invalid assignments fail fast without consuming database resources.<\/p>\n\n\n \t <\/p>\n <\/p>\n \t\t\t<\/div>\n \t\t\t \t\t<\/div>\n \t<\/section>\n \n\n\n\n Duplicate detection fits naturally in the prevalidation stage in Dynamics CRM. You want to catch duplicates before creating the record, not after.<\/p>\n\n\n\n If your organization enforces unique email addresses across all contacts, here’s how:<\/p>\n\n\n\n The check runs before the create operation begins. You avoid starting a transaction, attempting the insert, and then discovering the duplicate.<\/p>\n\n\n\n For complex duplicate detection\u2014multiple fields, fuzzy matching, calculated values\u2014evaluate whether prevalidation gives you enough context. Sometimes, pre-operation plugins provide better reliability when you need to compare more sophisticated criteria.<\/p>\n\n\n\n Building a prevalidation plugin in Dynamics 365 follows a straightforward process. Let’s walk through each step thoroughly.<\/p>\n\n\n\n Start by creating a new Class Library project in Visual Studio targeting .NET Framework 4.6.2 or later. Add the Microsoft.CrmSdk.CoreAssemblies NuGet package to get the necessary references.<\/p>\n\n\n\n Your plugin class needs to implement the IPlugin interface:<\/p>\n\n\n\n Build the project and sign the assembly with a strong name key. This creates the DLL file you’ll register with Dynamics 365.<\/p>\n\n\n\n Now comes the registration part. Open the Plugin Registration Tool and connect to your environment. Register your assembly, then register a new step with these settings:<\/p>\n\n\n\n The stage selection matters here. Prevalidation corresponds to stage 10 in the pipeline. This ensures your validation runs before security checks and before any database transaction begins.<\/p>\n\n\n\n You can register multiple steps for the same plugin to validate different messages or entities. Each step runs independently based on its configuration.<\/p>\n\n\n\n The validation logic retrieves necessary data, checks conditions, and throws an exception if validation fails. Here’s a complete example that validates email uniqueness:<\/p>\n\n\n\n Key points in this code:<\/p>\n\n\n\n The validation returns silently if everything checks out. If validation fails, the InvalidPluginExecutionException stops the operation and displays your message to the user.<\/p>\n\n\n\n Testing prevalidation plugins in Dynamics 365<\/em><\/strong> requires checking both success and failure scenarios.<\/p>\n\n\n\n Start with the Plugin Registration Tool’s profiler feature. Select your plugin step and click “Start Profiling.” This captures execution details, including any errors, timing information, and trace logs.<\/p>\n\n\n\n Add tracing to your plugin for debugging:<\/p>\n\n\n\n These traces appear in the Plugin Trace Log when you enable logging for your plugin step.<\/p>\n\n\n\n For local debugging, use the Plugin Registration Tool to download the profiler results. Then use the Plug-in Profiler Utility in Visual Studio to replay the execution with breakpoints.<\/p>\n\n\n\n Test these scenarios:<\/p>\n\n\n\n During bulk imports, check that invalid records fail with your error message while valid records succeed. The prevalidation plugin should handle high volumes efficiently since no transactions start for failed validations.<\/p>\n\n\n\n Monitor execution time in the Plugin Trace Log. Prevalidation plugins in Dynamics 365 should complete quickly\u2014aim for under one second. If validation takes longer, optimize your queries or reconsider whether prevalidation is the right stage.<\/p>\n\n\n \t <\/p>\n <\/p>\n \t\t\t<\/div>\n \t\t\t \t\t\t\t Below are some of the most frequent issues developers face when working with prevalidation plugins in Dynamics 365 and the right ways to prevent them.<\/p>\n\n\n\n\n
The Plugin Execution Pipeline in Dynamics 365<\/h2>\n\n\n\n
![\"Plugin](\"https:\/\/www.aegissofttech.com\/insights\/wp-content\/uploads\/2025\/05\/Plugin-execution-pipeline-in-Dynamics-365.webp\" "\\"Plugin")
<\/figure>\n\n\n\nPre-Validation (Stage 10)<\/h3>\n\n\n\n
\n
Pre-Operation (Stage 20)<\/h3>\n\n\n\n
\n
Main Operation (Stage 30)<\/h3>\n\n\n\n
\nLearn how we can improve system performance and save time for your team.<\/div>\nPost-Operation (Stage 40)<\/h3>\n\n\n\n
\n
What are Prevalidation Plugins in Dynamics 365?<\/h2>\n\n\n\n
When to Use Prevalidation Plugins<\/h2>\n\n\n\n
Preventing Invalid Record Imports<\/h3>\n\n\n\n
public void Execute(IServiceProvider serviceProvider)\n{\n var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));\n var serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));\n var service = serviceFactory.CreateOrganizationService(null);\n \n if (context.InputParameters.Contains(\"Target\") && context.InputParameters[\"Target\"] is Entity target)\n {\n if (target.LogicalName == \"contact\" && target.Contains(\"parentcustomerid\"))\n {\n var accountRef = target.GetAttributeValue<EntityReference>(\"parentcustomerid\");\n var account = service.Retrieve(\"account\", accountRef.Id, new ColumnSet(\"statecode\"));\n \n if (account.GetAttributeValue<OptionSetValue>(\"statecode\").Value != 0)\n {\n throw new InvalidPluginExecutionException(\"Cannot create contact linked to an inactive account.\");\n }\n }\n }\n}<\/code><\/pre>\n\n\n\nRestricting Unauthorized Updates or Deletions<\/h3>\n\n\n\n
if (context.MessageName == \"Delete\" && context.PrimaryEntityName == \"opportunity\")\n{\n var opportunityId = (Guid)context.InputParameters[\"Target\"];\n var opportunity = service.Retrieve(\"opportunity\", opportunityId, new ColumnSet(\"statecode\"));\n \n if (opportunity.GetAttributeValue<OptionSetValue>(\"statecode\").Value == 0)\n {\n throw new InvalidPluginExecutionException(\"Active opportunities cannot be deleted. Close the opportunity first.\");\n }\n}<\/code><\/pre>\n\n\n\nif (context.MessageName == \"Update\" && context.PrimaryEntityName == \"invoice\")\n{\n var invoiceId = ((EntityReference)context.InputParameters[\"Target\"]).Id;\n var invoice = service.Retrieve(\"invoice\", invoiceId, new ColumnSet(\"statuscode\"));\n \n if (invoice.GetAttributeValue<OptionSetValue>(\"statuscode\").Value == 100001)\n {\n throw new InvalidPluginExecutionException(\"Approved invoices cannot be modified.\");\n }\n}<\/code><\/pre>\n\n\n\nValidating Cross-Entity Business Rules<\/h3>\n\n\n\n
if (target.LogicalName == \"msdyn_workorder\" && target.Contains(\"msdyn_servicelocation\"))\n{\n var locationRef = target.GetAttributeValue<EntityReference>(\"msdyn_servicelocation\");\n \n var location = service.Retrieve(\"msdyn_servicelocation\", locationRef.Id, \n new ColumnSet(\"msdyn_maxcapacity\", \"msdyn_currentload\"));\n \n var maxCapacity = location.GetAttributeValue<int>(\"msdyn_maxcapacity\");\n var currentLoad = location.GetAttributeValue<int>(\"msdyn_currentload\");\n \n if (currentLoad >= maxCapacity)\n {\n throw new InvalidPluginExecutionException(\"Selected location has reached maximum capacity.\");\n }\n}<\/code><\/pre>\n\n\n\nAvoiding Duplicates During Create Events<\/h3>\n\n\n\n
if (context.MessageName == \"Create\" && target.LogicalName == \"contact\" && target.Contains(\"emailaddress1\"))\n{\n var email = target.GetAttributeValue<string>(\"emailaddress1\");\n \n var query = new QueryExpression(\"contact\")\n {\n ColumnSet = new ColumnSet(\"contactid\"),\n Criteria = new FilterExpression\n {\n Conditions =\n {\n new ConditionExpression(\"emailaddress1\", ConditionOperator.Equal, email)\n }\n },\n TopCount = 1\n };\n \n var results = service.RetrieveMultiple(query);\n \n if (results.Entities.Count > 0)\n {\n throw new InvalidPluginExecutionException($\"A contact with email address {email} already exists.\");\n }\n}<\/code><\/pre>\n\n\n\nHow to Build a Prevalidation Plugin in Dynamics 365<\/h2>\n\n\n\n
Step #1: Define and Register the Plugin<\/h3>\n\n\n\n
using System;\nusing Microsoft.Xrm.Sdk;\n\nnamespace AegisSofttech.Dynamics.Plugins\n{\n public class ValidateContactEmail : IPlugin\n {\n public void Execute(IServiceProvider serviceProvider)\n {\n \/\/ Plugin logic goes here\n }\n }\n}<\/code><\/pre>\n\n\n\n\n
Step #2: Implement Validation Logic<\/h3>\n\n\n\n
public void Execute(IServiceProvider serviceProvider)\n{\n \/\/ Get the execution context\n var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));\n \n \/\/ Get the organization service (using system context for universal validation)\n var serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));\n var service = serviceFactory.CreateOrganizationService(null);\n \n \/\/ Get the target entity from the input parameters\n if (context.InputParameters.Contains(\"Target\") && context.InputParameters[\"Target\"] is Entity target)\n {\n \/\/ Check if this is a contact with an email address\n if (target.LogicalName == \"contact\" && target.Contains(\"emailaddress1\"))\n {\n var email = target.GetAttributeValue<string>(\"emailaddress1\");\n \n \/\/ Skip validation if email is empty\n if (string.IsNullOrWhiteSpace(email))\n {\n return;\n }\n \n \/\/ Query for existing contacts with this email\n var query = new QueryExpression(\"contact\")\n {\n ColumnSet = new ColumnSet(\"contactid\"),\n Criteria = new FilterExpression\n {\n Conditions =\n {\n new ConditionExpression(\"emailaddress1\", ConditionOperator.Equal, email)\n }\n },\n TopCount = 1\n };\n \n \/\/ For updates, exclude the current record\n if (context.MessageName == \"Update\")\n {\n query.Criteria.AddCondition(\"contactid\", ConditionOperator.NotEqual, target.Id);\n }\n \n var results = service.RetrieveMultiple(query);\n \n \/\/ Throw exception if duplicate found\n if (results.Entities.Count > 0)\n {\n throw new InvalidPluginExecutionException(\n $\"A contact with email address '{email}' already exists. Please use a unique email address.\");\n }\n }\n }\n}<\/code><\/pre>\n\n\n\n\n
Step #3: Testing and Debugging<\/h3>\n\n\n\n
var tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));\ntracingService.Trace(\"Starting email validation for contact\");\ntracingService.Trace($\"Email address being validated: {email}\");\n<\/code><\/pre>\n\n\n\n\n
Common Mistakes and How to Avoid Them<\/h2>\n\n\n\n