A plugin is a small compiled .NET assembly (a DLL) that runs custom business logic on Dataverse, triggered automatically when something happens to a record. It runs on the server, not in the user's browser — that's the key difference from the client-side JavaScript covered in the JavaScript & Web Resources course.
- A plugin is a .NET assembly written in C#, compiled to a DLL
- It implements the IPlugin interface, with one method:
Execute - It's triggered by a message — Create, Update, Delete, and others
- It runs server-side, registered against a specific table and message
One checkpoint, one job
Think of a plugin as a checkpoint attendant stationed at one specific gate. They don't watch the whole building — just their one gate, for one specific kind of event. When someone passes through (a record gets created, updated, or deleted), the attendant does their one job: validate something, block the action, or set a related field.
A Dynamics 365 CE environment can have dozens of these "attendants" stationed at different gates — different tables, different messages — each running independently, unaware of the others unless a developer deliberately connects them.
Messages: what actually triggers a plugin
Every action taken against Dataverse is represented as a message: Create, Update, Delete, Assign, SetState, and more. A plugin is registered against one specific message on one specific table — for example, "run this plugin on Update of Account."
Create message of the Opportunity table runs every time a new Opportunity is saved — and never runs for an Update, a Delete, or any other table, no matter how similar the logic might seem useful elsewhere.
The IPlugin interface
Every plugin class implements IPlugin, a contract with exactly one method:
public class MyPlugin : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
// your logic goes here
}
}The platform calls Execute and hands it an IServiceProvider — a toolbox your code uses to pull out what it needs: the execution context (details about what's happening right now), a way to talk back to Dataverse (the organization service), and a logger (the tracing service). The next chapter covers the execution context in detail.
Why not just use a business rule or workflow?
The Customization course already covers Business Rules and classic Workflows — both no-code, both useful. A plugin is the tool you reach for when the logic is too complex for a no-code designer, needs to run synchronously as part of the save transaction, or needs to call out to external code (like an API) reliably.
| Tool | Runs where | Best for |
|---|---|---|
| Business Rule | Client-side, on the form | Simple field-level if-this-then-that |
| Workflow | Server-side, no-code | Simple background automation |
| Plugin | Server-side, compiled code | Complex logic, guaranteed synchronous execution |
IPlugin, registered against one message on one table, running server-side when that specific event happens. It's the tool for logic too complex — or too transaction-critical — for a no-code option.