Plugins Development in Dynamics 365 CRM | Part 2 – Registering your plugin

Given that you are coming here from the Part 1: https://d365demystified.com/2021/12/31/plugins-development-in-dynamics-365-crm-part-1-setting-up-visual-studio-project/

Let’s register our plugin to the Dynamics 365 CRM organization using the Plugin Registration Tool!

Log into Plugin Registration Tool

Based on where you have downloaded the Plugin Registration Tool, navigate to the folder and follow the below –

Open the Plugin Registration Tool from the directory.
Now, given that this is Dynamics 365 CRM Online (Customer Engagement / Dataverse) environment, you’ll make sure Office 365 is selected and then you’ll need to enter Admin Credentials.
Once successfully authenticated, you’ll be asked to choose which organization this is in. Given that development should ideally be done on a Dev/Sandbox environment, you’ll select the appropriate environment here.
Once logged in, you’ll see the the assemblies registered with the CRM environment. These are the out-of-the-box assemblies which are not supposed to be manipulated.

Register your Assembly

Let’s register the Plugin Assembly –

Click on the Register New Assembly button and click on New Assembly
You can now click on the three dots in order to navigate to the .DLL file which was generated when you Build the project.
You’ll then need to navigate to the bin folder (Either Debug or Release)
Once you select the .dll file, you’ll see the plugins which are exposed in the dll i.e. the Plugins of .CS of ‘public’ visibility.
Once this looks good, click on the Register Selected Plugins
Upon successful registration, you’ll see the below message.
And your Assembly will now be registered successfully using the Plugin Registration Tool.
In case this Project was not signed with .snk file, you’d see the below message.
“Assemblies containing Plugins must be strongly signed. Sign the Assembly using a KeyFile“

Now, the assembly has been registered. Next, we’ll add a step (you can call it a trigger for the plugin to start executing)

Register Step for Plugin

Now, let’s register a step for the Plugin –

Now, given that the Assembly was successfully Registered, the next step is to Register a Plugin Step.
Expand the Assembly, then expand the Plugin itself to which you want to add a Step.
As per the scenarios from Blog 1, the plugin is supposed to be triggered on change of the Account’s field Group Code.
So, when you click on Register New Step, you’ll get to configure the Step
Here, Message means the “operation” on occurrence of which the Plugin should be triggered. In this example, we want to trigger the plugin on an Update operation.
Primary Entity denotes which entity is this targeted at. Account in this example.
Then, the Filtering Attributes is available if the Message is set to Update since Filtering Attribute let’s you select which all fields should be listened to in order to run/trigger the plugin.
Clicking on the three dots, you’ll get to choose the fields. In this example, we’ll select the Group Code field.
Once you click OK after choosing what all fields the plugin should fire on, you should select “under whose security context should the plugin be running”
Run in User’s Context is that field to choose the user.
In my practice, I choose either Calling User or a System Administrator
Finally, I’ll choose “when in the context of the operation” should the plugin be triggered.
Since, I want the plugin to run “after” the “Update” operation is performed, I’ll select PostOperation.
And Execution Mode has options – Asynchronous / Synchronous defines if the plugin will run in the background or with the operation itself.
Once I choose these preferences, I’ll click on Register New Step and the Step will be registered on the Plugin.
At this point, you’ve successfully registered the plugin assembly and a step on the plugin to be triggered on the update of the Account field – ‘Group Code’.