Plugins in Dynamics CRM and Model-Driven Apps
In Model-Driven Apps, plugins are custom code components used to enforce business rules, modify data, or integrate with external systems. Both platforms run on the same underlying technology: Microsoft Dataverse.
Dataverse stores everything as tables (formerly called entities). These range from business data such as accounts and contacts to system artifacts like forms and views. Plugins attach logic to these tables by responding to system messages generated during data operations.
How Plugins Work: The Messaging System
Every user action triggers a message.
Example: when a user clicks Save on a contact form, the browser packages the submitted values into a payload called the Target and sends it to Dataverse.
This action produces a message such as Create or Update. The message then flows through a defined execution pipeline, where plugins can intercept and act on it.
Execution Stages
The stage at which a plugin runs determines what it can and cannot do.
Pre-Operation Stage
This stage runs before data is written to the database.
Plugins here can modify the Target directly.
Typical uses:
Formatting data (capitalizing names)
Setting default values
Constructing derived fields (for example, building a full name from first and last names)
Because changes occur before persistence, the database never stores the unmodified data. From the system’s perspective, the corrected data always existed.
Operation Stage
This is the moment when Dataverse commits the data to the database.
Developers do not typically place custom logic here; it represents the core system transaction.
Post-Operation Stage
This stage runs after the record has been saved.
At this point, the record has a unique identifier (Record ID).
Typical uses:
Creating or associating related records
Triggering follow-up updates
Initiating downstream processes or integrations that require the ID
Infrastructure and Development Tools
Plugin development is done using standard .NET tooling and Dataverse-specific utilities.
Visual Studio
Used to write and compile plugin code as a .NET class library.Plugin Registration Tool
Used to deploy plugin assemblies, register steps, configure execution stages, and attach images.Metadata and inspection tools
Used to identify logical (internal) field names so the code targets the correct columns.
Analogy: The Stadium Checkpoint
A plugin behaves like a security checkpoint at a stadium.
Pre-Operation is the guard checking your ticket and stamping your hand. Your status changes before entry.
Operation is the moment you pass through the gate.
Post-Operation is receiving your seat number. A seat assignment is impossible until you are officially inside.
The same logic applies to Dataverse: some actions only make sense before a record exists, others only after it has been created.
This execution pipeline is the core mental model required to design correct, predictable plugin behavior.
