Glossary
Plug-in
By Emil Björk · Microsoft business apps consultant, Gothenburg
Server-side .NET code that runs in response to Dataverse events — the most powerful customisation mechanism in the CRM-side Dynamics 365 stack.
A plug-in in Dataverse is a .NET assembly registered to run on specific Dataverse events (Create, Update, Delete, or a custom message). Plug-ins execute server-side in a sandboxed environment, with full transactional context — they can read related records, throw exceptions to cancel the entire operation, and modify the target record before it writes to the database. The plug-in pipeline has four stages: pre-validation (runs outside the database transaction, the right place to reject invalid input before anything is committed), pre-operation and post-operation (both inside the transaction, so an exception here rolls back the whole operation), and an asynchronous queued path that runs after the transaction has already committed.
In practice, the choice between synchronous and asynchronous — and between pre- and post-operation — is where most plug-in bugs originate. A synchronous plug-in blocks the user's request until it finishes, so a slow synchronous plug-in makes every save of that record feel slow to every user, while an asynchronous one queues for later and can't cancel the operation it's reacting to since the record has already saved by the time it runs. Registering business validation as post-operation-asynchronous, for instance, means the invalid record has already been committed by the time the plug-in objects to it — a design mistake that surfaces as "the validation sometimes doesn't seem to fire" reports weeks after go-live, when really it fired too late to matter.
Where confusion shows up: plug-ins are often reached for by developers coming from a traditional coding background because they're familiar and powerful, when the modern default in Dataverse increasingly favours Power Automate flows for anything that's really orchestration — calling another system, sending a notification, running a multi-step process — reserving plug-ins specifically for logic that must be transactional, performance-sensitive, or genuinely needs server-only execution the client can never be trusted to enforce (a security check, a calculation that must be atomic with the write). Defaulting to plug-ins for everything trades away Power Automate's visual maintainability for power that most integration logic doesn't actually need.
Related terms
Mentioned in these guides
- AI prompts in Power Platform
- Anti-corruption layers for Dynamics 365 integrations
- Architecture decision records for Dynamics 365
- Azure Service Bus integration with Dataverse
- Bulk delete jobs in Dataverse
- Business rules in Dataverse
- Calculated and rollup columns in Dataverse
- Capacity planning for Dynamics 365
- Change tracking and delta queries in Dataverse
- Circuit breakers in Dynamics 365 integrations
- Custom actions in Dataverse
- Dataverse alternate keys
- Async jobs in Dataverse
- Impersonation in Dataverse plug-ins
- Dataverse plug-ins explained
- Dataverse plug-in exceptions explained
- The Dataverse plug-in execution pipeline
- Dataverse secrets and Azure Key Vault integration
- Dataverse solution import errors
- Dataverse storage types explained
- Tracing and logging in Dataverse
- Dataverse Web API errors explained
- Dual-write sync errors
- KYC and client onboarding workflows on Dynamics 365
And 34 more — this term shows up across the library.