Hi Erik,
I am still not sure why you need multiple paths, though.
Here is what I did:
5 :
answer = checkCloseConditions();
function checkCloseConditions() {
var task = new GlideRecord('change_task');
task.addQuery('change_request', current.sys_id);
//task.addQuery('state','NOT IN','3,4,7,9'); //you can use this to indicate the un-required states
task.addActiveQuery(); //or use this, if you want them to be closed
task.query();
if(task.hasNext()) {
return false;
}
return true;
}
The advantage is that you can remove 2, 3, 4 because it works in two situations:
1. if the request is in state scheduled and there are no tasks, and the end user clicks on Implement, the change will move to implement and reach 6.
2. if the request is in state scheduled and there are tasks waiting, the change state can still be moved to implement, but the flow itself will not go past 5 until the tasks are closed. This will allow you to add more tasks in state Implement, although the flow will not continue until everything is closed.
Tell you the truth, I am unclear why you're branching it. How are tasks being opened? Because according to your flow, you don't need the second branch; if there are tasks, they will be closed before the first join, wait for Implement and once that state is reached, there will be no open tasks and the change will go straight to Review. If there are no tasks, the change flow will check for tasks, and if there are none, it will change state to Implement and move on automatically (wait for condition Implement will be reached, then check again for non-existent tasks, set the state to review and so so on).
harel
