The Microsoft Dynamics CRM workflow is driven by a study engine that provides the much-needed powerful functionality for implementing personalized business logic in a typical CRM deployment. Meanwhile, it also exposes itself to complicated problems and design errors that can cause expensive maintenance, leaving behind a group of confused users. However, there are crucial considerations when implementing workflows/custom workflow activities in Dynamics CRM.
Dynamics CRM Workflow – Best Practices
1. Composition with Child Workflows
In general, the workflow pattern is composed of smaller steps. So, in your workflow creation, keep in mind the particular sections of the workflow that you can generalize as a “sub-process” to allow reuse in multiple workflow definitions.
Isolating these smaller processes means that one can easily define child workflows to be “called” from the multiple workflow definitions. One major advantage is that is becomes easy to modify child workflows rather than trying to modify multiple workflow definitions. Defining future workflows, most probably composed of smaller processes called business logic, is also made simpler. A critical consideration is that execution of child workflows happens asynchronously in relation to the parent workflow. So, avoid using child workflows for sub-processes that execute in a sequence.
2. Beware of Persistence Points in Workflow Definitions
Long workflows take long to execute, and if you have one, you must consider it will persist and what this really implies. Workflow persistence could be for various reasons:
The workflow instance could be waiting for an event to occur;
The CrmAsyncService is stopped;
The workflow instance clearly requests to be persisted through executing an activity with the PersistOnCloseAttribute.
In fact, the workflow instance is unloaded by the workflow engine, persisting it to the database up to the point where a user will manually resume the workflow, or the happening of an event that will cause the workflow to resume automatically. Below are the vital considerations:
At what point exactly does the workflow persist? It will persist up to that point when the final activity is labeled as a persistence point. So, on resuming, it re-executes all the steps that come after the last persistent point. The importance of this is that the logic point in your workflow is guaranteed to execute only once (not more). However, the workflow instances are persisted (automatically) after these CRM steps: create, update, assign, send email, change status, send email from template, child workflow and stage.
When will the workflow resume? If the workflow has to wait for an event that might never take place or take several years to occur, then it is unfortunate that the database, eventually, will contain thousand of workflows on the waiting list, which could greatly affect performance. It is better to consider a design with the situation minimized. For instance, a workflow waiting on an opportunity to be labeled as “won” may wait forever, yet the condition is never met. A good practice is to wait on an opportunity to be closed before checking the status. The reason is that once marked as closed (if not marked as “won”), you may have to add a Stop Workflow step right there.
3. Write “atomic” Custom Activities
First, understand that custom workflows are not meant to implement the entire workflow logic, but are rather small “atomic” steps that would form part of larger workflows. Since custom activities are not capable of controlling persistence, they should never be the sole reason for workflow idleness, or should not persist right in the middle of a custom activity.
In general, it is much better to have numerous custom activities called in sequence from one parent workflow than a single large custom activity implementing all the logic in sequence. It follows from the general principle of workflow as a typical composition pattern. For instance, if your design process is to perform custom actions X,Y and Z when an account is opened, then it better to just write a custom activity for each X, Y and Z separately, adding a step for each activity in that particular workflow, rather than writing a custom activity to implement X,Y and Z sequentially then adding one step to the workflow that includes this custom activity.
4. Correct use of “Execution Time” provided by Dynamics CRM workflow designer
The Dynamics CRM workflow designer normally provides a property known as “Execution Time,” potentially useable in various dynamic expressions, including “if Account(CreatedOn) + 10 days < workflow(ExecutionTime)”. This property doesn’t mean the time when the workflow is published, neither does it mean the start time of the workflow instance.
On the contrary, this property’s actual value is the real time the workflow evaluates an expression containing the property. So, expressions like “Wait until 1 day after workflow(ExecutionTime)” won’t succeed and this workflow will wait only to resume once a day (this is repeated to infinity), causing performance problems. Therefore, if you want your workflows to have a specific wait time use the wait step and ensure you configure the condition as follows: workflow – timeout – equals – {Duration}. The advantage with this is that it will unload the workflow and then resume execution after your specified time period has elapsed.
5. Plugins vs. Workflows
A common dilemma for Dynamics CRM developers is when to use plugins vs. workflows. The answer is that there is no exact formula for choosing the best implementation method for a particular situation. The right approach is determined by the variables of the task you want to accomplish. But generally, the most decisive factor is whether or not the developer needs a synchronous action; if yes, plugins carry the day, if not then other factors should be considered.
Conclusion
A study engine drives Dynamics CRM, providing powerful functionality for implementing fully customized business logic during CRM deployment. Complications and design errors can result in expensive maintenance and leave behind a large group of confused users.
Isolate smaller processes to easily define child workflows so that they can be called from various workflow definitions to make it easy to modify child workflows, instead of trying to modify various workflow definitions. Workflows are not meant to implement the entire workflow logic but form part of larger workflows. Lastly, while there is no exact formula to apply when choosing the best implementation method (plugins or workflows) for a particular situation, the most decisive factor will depend on whether or not the developer needs a synchronous action in the Dynamics CRM workflow.
