Writing the code is only half the job — a plugin does nothing until its compiled assembly is signed, uploaded to Dataverse, and wired to a specific message and table through a registered step. This chapter walks through that path in order, from a finished project to a plugin actually firing.
- Plugin assemblies must be strong-name signed before they can be registered
- The Plugin Registration Tool (or XrmToolBox equivalent) uploads and wires up the assembly
- Online environments require Sandbox isolation mode
- Registration happens in three layers: assembly → step → image
Step 1 — Sign the assembly
Dataverse only accepts plugin assemblies that are strong-name signed — a .NET mechanism that gives an assembly a unique cryptographic identity. In Visual Studio:
- Right-click the plugin project and open Properties.
- Go to the Signing tab.
- Check Sign the assembly.
- Under key file, choose New to create a strong-name key file (a
.snkfile), or select an existing one if the project already has one. - Rebuild the project so the compiled DLL is produced with the signature applied.
Keep the .snk file with the project source — if it's lost, a later rebuild will produce an assembly with a different identity, which complicates updating an already-registered plugin.
Step 2 — Open the Plugin Registration Tool
The Plugin Registration Tool (distributed as part of the Power Platform CLI tooling, and also available as a plugin inside XrmToolBox) is the standard way to get an assembly into Dataverse. Open it and create a new connection to the target environment, signing in with an account that has sufficient privileges to register plugins.
Step 3 — Register the assembly
Choose Register → Register New Assembly, browse to the compiled, signed DLL, and select an isolation mode. For Dataverse online, Sandbox isolation is required — it runs the plugin in a restricted, monitored process so one plugin can't destabilize the whole environment. Confirm and register; the tool uploads the assembly and lists the plugin classes it found inside.
Step 4 — Register a step
A step is what actually connects your plugin class to a real event. Right-click the registered assembly (or the specific plugin class) and choose Register New Step, then set:
- Message — the event to listen for, e.g.
Create,Update,Delete. - Primary Entity — the table the step applies to, e.g. Account.
- Stage — pre-validation, pre-operation, or post-operation, covered in the pipeline chapter.
- Execution Mode — synchronous or asynchronous, covered in the sync vs. async chapter.
Step 5 — Register an image, if needed
If the plugin needs to see field values before or after the core operation — a pre-image or post-image, as covered earlier in this course — register it now against the step, specifying which attributes to include. Skip this step entirely if the plugin only works with the data already present in the incoming request.
Step 6 — Test it
Perform the action that should trigger the plugin in the actual app — create a record, change a field, delete a row — and confirm the expected effect happened. If nothing seems to have happened, the next chapter covers reading the plugin's trace logs to see what actually ran.
| Setting | What it controls |
|---|---|
| Message | The event that fires the step (Create, Update, Delete, Assign, and others) |
| Primary Entity | Which table the step listens to |
| Stage | Pre-validation, pre-operation, or post-operation |
| Execution Mode | Synchronous (blocks the save) or asynchronous (runs after) |
| Deployment / Isolation Mode | Sandbox (required online) vs. None (on-premises only) |
estimatedvalue changes: Message = Update, Primary Entity = Opportunity, Stage = pre-operation (so the stamped date rides along in the same save), Execution Mode = synchronous. No image is needed here, since the plugin only reads the incoming Target — it doesn't need to compare against the old value.