of the
In yesterday’s tip we suggested to avoid wait conditions altogether; but if you must use them:
- Combine waits and check condition. So you have a process that emails a customer service representative three days after the case is open. No need to email them if the case has been closed, right? After the wait, have the workflow check conditions to verify that the condition that triggered the workflow is still true. If not,
cancelclose the workflow. - Use a child workflow for your action that happens after the wait is done.
- Use short wait periods. 5 minute waits are ok. 2 year waits are bad.
- Use timeouts rather than wait conditions
I would suggest that for anything that needs a long wait* you should call a child workflow to do the waiting, and then that calls a child to do the follow-up action. This allows you to change any one of the parts without disrupting the “in flight” workflows. And for the most part, the only workflows in flight will be the waiting ones. So you can change the logic of the initial part that makes decisions, or the actions taken after the wait with no great difficulty.
You can also change the logic of the waiting part (eg how long to wait, or adding a parallel wait to drop out early) and the only thing that will fail is the call to this workflow while it is offline. You can rename, reactivate and then resume those that tried to call it and they will work happily (as long as the time it takes you to edit is less than the usual wait time, or the exact timing is non-critical, this approach is OK).
You can kick off a whole bunch of new waiting workflows using an on-demand “trigger” workflow, based on an advanced find query of records that have an old waiting workflow instance against them. Then find the old workflow system jobs related to records that have a new waiting workflow against them as well (because it has a new name, or based on start time) and cancel those.
*how long is a LONG wait? Longer than it take the business to change their mind or their processes.
In some organizations with very formal change management procedures, this could be months.
In some businesses, it seems that the CEO will just turn around and decide the wait in a sales process until two months before the end of a contract agreed in yesterday’s meeting with 20 people should be only one month, and it must be changed as of NOW, and retrospectively. Tomorrow he might change his mind again…
[…] fellow tipster Joel suggested in his last tip some fine tuning when it comes to […]
Hey guys, quick question…if I have a workflow that has a bunch of system jobs currently in wait steps, can i deactivate it to make some quick changes? Or I should add, will those waiting processes be killed or would they potentially still be waiting when I re-activate?
existing waiting steps don’t get killed when you deactivate. If you deactivate, make changes, and then republish, the existing waiting instances will still be active with the original definition–they don’t automatically inherit the changes you make when you update the workflow. That is the reason for the tips in the waiting workflow category recommend using child workflows for the Action step–that way you can change what happens and have existing waiting instances call the child process, and changes made to the child workflow will get included when the wait condition is up.