In this blog post I will be discussing a few ‘best practices’ when using Dynamics CRM 2011 Workflow Processes, and in particular when using the ‘Wait Condition’. I will assume that you’re familiar with the basics of how to use workflow wait conditions, and so I will be focusing purely on a few of the tricks that I’ve picked up over the years while using workflows, so that you can use them in the most effective manner possible.
1. TRY AND AVOID USING TIMEOUTS WHERE POSSIBLE
While a timeout is technically a wait condition, it appears differently once saved. Unlike a standard wait condition, a timeouts wait condition cannot later be modified, unless it is to simply change the date it is waiting until (as in, it must remain a ‘timeout’).
A timeout also cannot have multiple conditions defined within the same timeout; for example waiting until a date is reached and the status is complete (meaning the condition won’t be met until both of these are true).
We can achieve most of the timeout functionality by simply using the process execution time. Since the process execution time is always the current time, we can construct a wait condition that, for example, waits until process execution time is on or after the due date (or any other date). This means the workflow will continue waiting, and the execution time will continue increasing until the dates align and the condition is met.
The only reason to use a timeout instead of the process execution time is if you want to wait a set number of days using the ‘duration’ timeout, for example: wait 7 days durations. If the workflow was only triggered on create however, you could still achieve this by waiting until the process execution time is X days after created on.
2. ADD STEPS AFTER THE WAIT CONDITION INSTEAD OF INSIDE
Wait conditions with no steps defined inside the actual wait condition will still wait until the condition is met before processing any steps after the wait condition.
By using this approach, it means there aren’t as many nested conditions, which makes it a lot easier to make changes to the workflow later on. When you delete a wait condition, it also deletes any steps defined within the wait condition, which means you would have to recreate any of the steps defined within the wait condition. It also means you can add your steps in first, and then add in the wait condition later.
If you have a parallel wait condition, where one of the two branches end the workflow, you can add the steps to end the workflow inside the wait, and then the steps for the other wait can be added outside (after) the whole wait condition. This will never be hit when the other wait condition is met, as the workflow will have been ended.
3. DON’T WAIT UNTIL A DATE, WAIT UNTIL ON OR AFTER A DATE
When waiting to reach a date (let’s call it the due date), wait until ON OR AFTER the due date, instead of waiting until the exact due date (using EQUALS). If the due date is changed to be before today, the workflow will continue waiting forever, as the current date will never ‘equal’ the due date again.
If you wait until ‘on or after’, the workflow will stop waiting when the date is changed to be in the past. Also if the server goes down during the exact time of the due date, the workflow will continue working as expected, and stop the wait after the server is back up.
4. TRIGGER WORKFLOWS ON CREATE WHEN USING A WAIT CONDITION
A Workflow triggered on Create will only ever run once for each record, whereas a workflow triggered by other means (such as field change) will fire a new instance of the workflow each time. If you are performing wait conditions, or sending emails for example, you don’t want these being sent twice for the same record.
If a date (such as an end date) won't be entered right away, and you only want to start waiting when this date is entered, you can still trigger the workflow on create, and just wait until on or after this date. Even if there is no value, the workflow will wait until there is a value, and until that value has passed. If the workflow was triggered on change of the end date, you could potentially have multiple instances of the workflow running if the date were to change after it was initially set.
There are a few issues with this approach however. The workflows could potentially be waiting a long time before the date is set and reached, or the date could never be set at all, in which case the workflow would continue to wait forever. There are 2 ways to avoid these issues:
• Add a parallel wait branch to the wait condition, so you can wait a static length (such as 3 months after the created on). If the end date is not set and reached by that time the workflow will end, and optionally send someone an email or perform some other action.
• Trigger the workflow on change of the end date, but create a new hidden date field on the entity to prevent multiple instances of the workflow running at once.
In the workflow, before the wait condition, set the hidden date field to equal the end date. Add a parallel wait condition to wait until the end date does not equal the hidden date field. If this condition is met, end the workflow (as another instance of the workflow will now be running). This will ensure only 1 instance of the workflow is running per record.
5. CHECK THE DATE IS IN THE FUTURE BEFORE WAITING
If historic records are being created/updated, you may not want your workflow to continue processing. This would require a simple check condition before the wait condition to check Process Execution time is BEFORE the date you are waiting for. If the date is not in the future, the workflow would not continue.
This would mean that if your workflow was running on change of the date field, and it was changed to a date/time before today, the new instance of the workflow would be ended as the date is not in the future. Assuming you had ended any earlier workflows, this would mean the steps defined after the wait condition would not fire for that record.
This check would be completely optional and dependant of your particular requirements, as you may need the workflow to fire even on records where the date is set in the past.
