Hopefully you've read our blog about Time and Condition Based Workflows in CRM 2011. Now, have you ever set up a workflow that was triggered from a field change and included a wait condition and/or timeout? Have you ever looked at what happens if the trigger field is changed frequently?

Consider this simple example: In CRM 2011 we want to track when an Account moves their business from one location to another. When the move is announced we create a move record, put in the new address, and set the date of the move. We create a workflow to send an email to the account manager so the address change can be recorded in our ERP system, then we wait for the move date to arrive to update the Account record with the new address. No problem! Here is our form:

And here is our new Workflow that is triggered when the record is created or when the "Move Date" field is changed. This workflow will do precisely what was described; it will email the account manager about the move date and update our Account with the new address info when the date in Move Date is reached. Let's try it!

Hey look! An Awesome Company is moving from Minneapolis to Honolulu on November 9^th, and our workflow is doing just what we wanted; it sent our email and now it's waiting for the move date!

Everyone at An Awesome Company is excited about this move (can you blame them, really?), but as we know, things happen, and An Awesome Company had to postpone this move until the end of the month. No problem, let's go change that move date. Our workflow should… oh wait…well, let's see.

Now we have two entries in the Workflow list! CRM was smart enough to update the "Postpone Until" date to our new move date in the first workflow, but because we changed the Move Date, another workflow ran and we now have two workflows waiting. This means in our System Jobs there are now twice as many pending jobs than we actually need.

Since CRM updated the "Wait Until" time on BOTH workflows to the new Move Date, in this simple scenario, it would be most efficient to separate the timeout workflow and the email workflow to two different workflows. Create a workflow to send the email message when the Move Date field changed and enable it to be used as a child process. Create another workflow for when the record is created that begins the wait for the Move Date. Add the child process for the email to the workflow that runs when the record is created.

But what if your scenario that includes a wait/timeout is not that simple?

Let's handle this workflow a little more elegantly, shall we?

We've added a new Whole Number field to the Move Entity called "Count". Count starts out empty when the record is created, so we will increment it by one. If the workflow is run again, the new workflow will increment the Count to 2.

Then we add wait condition. The wait condition is waiting until the Count is more than 1. When that happens, it will set the Count back to 1 and cancel the workflow.

Next we're going to add a Parallel Wait Branch so the workflow will continue if one of the two wait conditions is met. The second condition is the timeout until our Move Date comes up. When the Move Date comes up we're going to update the Account with the new address and celebrate our brilliance with a successful workflow status.

Let's try it. I've deleted the first move to Hawaii because of the double waiting workflow issue, so I'm starting fresh with a new record. This time the first Move Date is 11/9/12, and you can see that the workflow is waiting. Will the Count switch to more than 1 or will the Move Date arrive?? Ahhh, the anticipation is killing me!

Let's postpone that move until 11/30/12. We can see that workflow found that the Count was more than 1, so the first workflow was canceled. Changing the value in the Move Date kicked off a new workflow which is now waiting for the Count to be more than 1 or for the Move Date to arrive.

Well, I don't know about you but I can't wait for this move. Let's move An Awesome Company to Hawaii TODAY!

Look at that! We switched the date to today. That started a new workflow, but since the Count went to 2, the 2^nd instance of the workflow was canceled. In the new workflow the Move Date timeout was met, updating our Account address and reporting Success! Someone hand me a Mai Tai, I need to celebrate!

Best of all, we don't have a bunch of duplicate workflow jobs waiting in the Suspended queue, which means the completed or canceled jobs can be cleaned up with maintenance and we don't have unnecessary records in the database.

Now that you're all ready to start thinking about canceling extra workflows, here is another article with some cool things you can do. Check out Create a Workflow in CRM to Alert a Record's Owner When an Activity/Note Is Added.

Happy CRM'ing!