When to Use Plug-Ins with Dynamics 365
Plug-in vs. Client-side Code
The differentiation is clear. Plug-in runs server-side with compiled code and should always be the preferred method of implementing business logic. Client-side code is vulnerable to different client environment, browsers, browser settings, etc, and should not be relied on implementing business critical steps.
On the other hand, anything requiring UI or user interaction, must be done with client side code. You will not be able to modify UI or prompt the user during processing with the plug-in.
Plug-in vs. Processes
These are very similar, in fact workflows are just a skin on an asynchronous system plug-in. The main differences:
- Workflows can only be triggered asynchronously
- Workflows can only be triggered online
- Workflows have limited triggers. Mostly these would be your basic create/update/delete/assign/state change.
- Plugins support different event execution pipelines. Workflows are always post operation.
- Workflow execution logic can be easily modified, this allows encapsulation of code in custom workflow activity while still retaining possibility of frequent changes on execution logic by non-programmers.
Synchronous vs. Asynchronous Plug-ins
Synchronous plug-ins are executed by the CRM Core System. Synchronous execution means that triggering event will wait until the plug-in finishes the execution. For example, if we have synchronous plug-in that triggers on the creation of account and user creates account record in CRM, the form will hang at save until the plugin has finished.
Asynchronous plug-ins are executed by asynchronous service. Asynchronous plug-ins allow triggering event to finish before plug-in code runs. Therefore these can never be used to prevent an action, validate data entry, or provide any error messages back to the user.