Plugins are basically .NET assemblies where we can write custom logic that we want to register in Dynamics 365 CE for specific events. Every plugin is associated with an event. You can view all the predefined plugin events for Dynamics 365 CE at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/supported-messages-entities-plugin or you can create your own custom events using actions in Dynamics 365 CE.

Once the development of our assembly is complete, we need to register it in Dynamics 365 CE. When registering our plugin for Dynamics 365 CE, we need to specify the execution stage. These execution stages identify whether our custom logic will run before or after Dynamics 365 CE's main database operation:

Registering a plugin consists of the following stages:

1. PreValidation is the first stage, which occurs before the main database operation. At this stage, the security role of the user is checked to verify whether they have the required permissions to perform entity operations.
2. PreOperation is the second stage, which also runs before the main database operation. At this stage, all the security checks are performed for the user to make sure they have the correct permissions to perform entity operations. We can use this stage to prepopulate entity fields; for example, by generating an entity number for an entity. We can also use this stage to run logic that we want to run before data is saved in the primary entity that our plugin is registered in. For example, let's say we want to create the record for entity A before entity B is created; here, we can write a pre-operation plugin on entity B, and there, we can write logic to create entity A.
3. MainOperation is the stage in which the system performs the main database operation. We can't associate any logic at this stage.
4. The PostOperation stage runs after all the main database operations. We can use this stage to run logic that should run after the database operations are complete. Let's say we want to create a customer record in a legacy system once it has been created in Dynamics 365 CE; here, we can write a PostOperation plugin on the customer entity and write our logic there to create a legacy system record.

Apart from the plugin stages, we can also decide whether we want to run our plugin logic synchronously or asynchronously. A synchronous plugin runs immediately after the trigger and waits until the logic is executed completely. The system won't respond until the execution is complete, which means we can't use the system until the plugin is executed. An asynchronous plugin is run in the background by an asynchronous service. These plugins don't immediately run our logic as there may be other processes in the asynchronous process queue. While this plugin is executing, we can use the system and perform other operations since this plugin doesn't keep the system busy and runs in the background.

All synchronous plugins run under a transaction, which means that if we are running our logic in a synchronous plugin and an error occurs, all the changes that were made by our logic will be rolled back. To understand this clearly, let's say that, in our plugin, we are creating three entity records. During the execution of our plugin, while creating the third entity record, if we get an error, it will roll back the first and second entity records we created as well. Asynchronous plugins do not support transactions.

We can write our plugin and register it manually using the plugin registration tool or we can use the developer toolkit. We will demonstrate writing and deploying plugin code manually in the next section.