Registering a plugin step

To register a new step in the plugin class, the user can just right-click on the plugin class appearing under the plugin assembly. One the user does that, the following screen should load up:

Mentioned here are some of the key terms along with their definitions:

• Message: This describes the event on which we are registering the plugin. Possible values can be Create, Update, Delete, Retrieve, RetrieveMultiple, AddListMembers, and so on.
  Basically, most of the actions that are happening in Dynamics CRM will have an associated message on which we can write a plugin.

• Primary entity: This is the Dynamics CRM object on which we want to register the plugin. The user can register plugins on all the custom entities that they create in Dynamics CRM. Apart from those custom entities, users can also register plugins on out-of-box entities such as account, contact, campaign, marketing list, and so on.
• Secondary entity: This is only applied to a very limited number of messages, such as SetRelated and RemoveRelated. When we register a plugin on the SetRelated message, the entity defined in the primary entity becomes the parent and the entity defined in the secondary entity becomes the child entity.
• Filtering attributes: These are only used in update messages. The idea of the filtering attribute is to only trigger the plugin when the attributes defined in the filtered attributes list is updated.
• Event handler: This is the name of the plugin class.
• Step name: This field is auto populated based on the entity and the message that we select.
• Run in the user's context: By default when we register the plugin, the plugin always executes as per the calling user security profile. This means that any call that the plugin may make to the Dynamics CRM organization service will be as per the security permissions of the calling user.
  However, in certain cases, we may want the plugin to always execute as per the security context of a user. In such a case, the user may select this option and deliberately select the required user in the drop-down list.

• Execution order: In some cases, for an entity, we may have to register more than one plugin in the same event pipeline stage. Due to this, if we want the plugins to follow a certain order of execution, we must define the execution order of the plugins accordingly.
• Event pipeline stage of execution: As discussed previously, we can register a plugin in three events, PreValidation, PreOperation, and PostOperation, depending upon whether we want the plugin to execute before the main operation, after the main operation, or in a different transaction altogether.
• Execution mode: A plugin can be executed either synchronously or asynchronously. If there is any operation for which we must wait for the execution to complete, we must register the plugin in a synchronous mode. Otherwise, if there is some complex logic that may take some time, we can set it asynchronously. note that in Dynamics CRM, the timeout setting for a plugin or the time that a plugin should finish execution in is 2 minutes. If it takes more than 2 minutes, the execution will automatically be stopped by the event pipeline.

• Deployment: This specifies where the user would like the plugin to be deployed. There are two possible options:
  1. On the server
  2. On Dynamics CRM for Outlook with offline access
  3. Both the possible options
• Secure and unsecure configuration: Secure and unsecure configurations are used to pass arguments to the plugin. Secure configurations can be read only by CRM administrators. On the other hand, insecure configurations can be read by any user in the CRM.
• Delete AyscOperation if StatusCode = Successful: When a plugin executing asynchronously completes an operation, a record of the system job is created in Dynamics CRM. It can be accessed from Settings | System Jobs:

If the user checks this option, it's an indication to the user about deleting the system jobs if the status of the asynchronous plugin is successful.