I fell into this trap quite recently when it came to writing a workflow in MS Dynamics. Now, let me tell you, I have been a MS Dynamics Developer/Architect/Consultant for a good few years now so consider myself close to expert in a lot of areas in this field. But, would you believe, one thing that I never had the pleasure of doing up until recently was using wait conditions and timeouts within a workflow. My scenario was thus:
User creates a quote Quote is linked to an "event" which has an "event start date" If user doesn't proceed with the Quote: leave open until the event has passed When the event passes, the quote/opportunity is closed as lost.Ok, easy workflow I hear you say. And so it should be. I browse online to find the best way to do this and come across a blog post with the following in the title "Workflow Wait Conditions: Best Practices - Dynamics CRM 2011". This is my gold! It's on community.dynamics.com so it cannot be wrong! Right? ... Nope, unfortunately it was flawed! Here's what caught me - from using the advice on that post I decided a timeout was a bad idea, so attempted to use a wait condition instead. And a direct quote from the blog was this:
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...This statement is incorrect, but I was not to know this yet. So I proceeded to create a wait condition for the following:
Wait Until Process Execution Time > Event Start Date.And you guessed it, my process never completed. Why? The process execution time is actually the start time OR the resume time, so it never changes unless you stop and start your workflow. Therefore it is not always the current date/time. A quick search of the internets and I find a different blog quoting the exact opposite.
So folks, moral of the story, don't believe everything you read out there. Always, always, ALWAYS double check your sources!