Every plug-in that we register is dependent on the event execution pipeline. Event plug-ins are divided into the following four stages, where each stage has its own significance.
This is the first stage where we can register our plug-in. In this stage our business logic runs before the system main operation which means that, up to this point, there is no validation done for the user who is responsible for code execution; for example no security checks are done for the user if he has the privileges to perform the action that he is trying to do through the plug-in. Plug-ins at this stage fire only once if a compound operation is involved; for example we have the business logic to set up a related contact record when an account is created:
Plug-in pipeline
This is the second stage where we can register our plug-in. Up to this stage, all validation and security checks for the user are done. They also execute before the main system operation. At this stage our business logic runs under the database transaction, so any business logic that we want to execute before the main system operation (such as auto-generation of unique IDs, financial calculations, and so on) should be registered at this stage.
This is the stage where the main core operations are executed by the CRM platform. So all the operations such as create, update, delete, and so on, are appended at this stage. There aren't any options to register our business logic at this stage.
This is the last stage where we can register our custom code. Plug-ins registered at this stage run after the main system operation, so any logic that we want to run after the main system operation can be registered here—for example, if we want to pass information from the CRM system to the ERP system once the operation is completed in the CRM, we can utilize this stage to do so.
A plug-in is always bound to a specific event. Any plug-in registered under an event will be executed if the corresponding request is sent to the CRM platform using the CRM UI or any other server-side utility. For example, let's say we have an account where a create plug-in is registered; this plug-in will fire every time an organization service create request is executed from the CRM UI, such as a create and import operation or any other Web service call.
Microsoft Dynamics CRM SDK comes with a file of a complete list of possible plug-in events that can be used for registering custom logic. This file can be found in SDK Message-entity support for plug-ins in CRM 2015 SDK.