It’s important to know when and how to use plugins and custom workflows to build smart and easy-to-manage solutions in Microsoft Dynamics 365 CRM. The real-life examples below show different situations and help you choose the right automation method for each one.
1. Execution Order: Synchronous Plugin, Asynchronous Plugin, Real-Time Workflow, On-Demand Workflow
Scenario:
You have all of the following registered on the same entity:
- Synchronous Plugin
- Asynchronous Plugin
- Real-Time Workflow
- On-Demand Workflow
Question: What is the execution order of these components?
Answer:
The actual execution order is as follows:
| Order | Component | Mode |
|---|---|---|
| 1 | Pre-Validation Plugin | Synchronous |
| 2 | Pre-Operation Plugin | Synchronous |
| 3 | Core Platform Save | CRM Action |
| 4 | Post-Operation Plugin | Synchronous |
| 5 | Asynchronous Plugin | Async Queue |
| 6 | Real-Time Workflow | Synchronous |
| 7 | On-Demand Workflow | Manual |
2. Preventing Record Creation Without Required Field
Scenario:
You want to stop users from creating a Contact without an email address.
Solution:
Use a synchronous plugin registered in the Pre-Validation stage.
Why:
Plugins can cancel the operation before data is saved. Workflows, including real-time workflows, cannot prevent the save from happening.
3. Creating a Task After a Case is Created
Scenario:
You want to automatically create a follow-up Task when a Case is created.
Solution:
Use a post-operation plugin or a real-time workflow.
Why:
Both run after the record is saved. Plugins are more efficient for complex logic, while workflows are better suited for simpler, configurable actions.
4. Business Users Want to Modify the Logic
Scenario:
A non-developer wants to change the logic executed when a Lead is qualified.
Solution:
Use a real-time workflow or a custom workflow activity exposed within a workflow.
Why:
Workflows can be modified without code and deployment. Custom workflow activities allow code reuse while remaining configurable through the CRM UI.
5. Background Processing After Opportunity is Closed
Scenario:
You need to send an email and update related records after an Opportunity is closed, without delaying the user.
Solution:
Use an asynchronous plugin or asynchronous workflow.
Why:
Asynchronous plugins are suitable for complex or high-volume logic. Asynchronous workflows are easier to set up for simple processes.
6. Reusable Logic Across Workflows
Scenario:
You have a business logic (e.g., checking a customer’s credit limit) that should be used across multiple workflows.
Solution:
Create a custom workflow activity and reference it across workflows.
Why:
It promotes code reuse, centralization of logic, and easier maintenance.
7. Canceling Record Save with Error Message
Scenario:
You want to prevent saving an Account record if the name contains restricted keywords and show an error message to the user.
Solution:
Use a synchronous plugin in the Pre-Operation or Pre-Validation stage.
Why:
Plugins can throw an exception to block the transaction. Workflows do not have this capability.
8. Execution Before and After Save
Scenario:
You need one logic block to run before save and another after save.
Solution:
Create two plugin steps:
- One in the Pre-Operation stage
- One in the Post-Operation stage
Why:
This provides control over the order and behavior of your logic around the record lifecycle.
9. Logic Triggered Manually by User
Scenario:
Users should be able to manually trigger escalation logic on a Case.
Solution:
Use an on-demand workflow or Power Automate flow.
Why:
On-demand workflows can be manually triggered via the UI. Plugins cannot be triggered directly by users.
10. Integration with External APIs
Scenario:
You need to call a third-party API when a record is updated.
Solution:
Use a plugin, ideally asynchronous if the external operation is time-consuming.
Why:
Plugins support API integration with better error handling and retries. Workflows are not ideal for complex integrations.
11. Updating Many Child Records When Parent Updates
Scenario:
You want to update hundreds of child records when a parent record is modified.
Solution:
Use an asynchronous plugin on Post-operation stage to handle child record updates using ExecuteMultiple for efficient processing.
Why:
Plugins are optimized for bulk operations, whereas workflows may perform poorly under high volume.
Regarding question 11: As per MS official documentation, it is not advised to use Bulk operation requests such as ExecuteMultiple in a plugin. So we can perform the operation in asynchronous plugin registered on post operation stage.