Problem with Wait For Condition in Workflow

chris_choi
Giga Contributor

In our Change Process we have a change_task state of cancelled which = 9 that is not in our task states.

 

We have a Wait for Condition in our Change workflow that tries to check to make sure all change tasks are closed before moving forward. The change Tasks are created manually and do not have an associated workflow activity, therefore the wf_activity = " " add query.

 

What we found was when the change task is put into closed complete the wait for condition returns true, however when the change task is put into cancelled the wait for condition just hangs up. As a test I changed the cancelled parameter to pending which is -5 and the wait for condition would return true if the change task was put into pending. The only thing I can think of that is different is that cancelled is not on the task states list however, the GlideRecord is looking at change_task so not even sure if this is a factor.

 

I also tried removing the gr_tsk.addQuery('wf_activity', '');   line in case that was it but to no better results.

 

answer = ifScript();

function ifScript() {

var gr_tsk = new GlideRecord("change_task");

gr_tsk.addQuery('change_request', current.sys_id);

gr_tsk.addQuery('state', '!=', '3');   //Closed Complete state

gr_tsk.addQuery('state', '!=', '9');   //Cancelled state

gr_tsk.addQuery('wf_activity', '');

gr_tsk.query();

 

if (gr_tsk.next()) {

    return false;

}

    else { return true;

 

 

}

}

1 ACCEPTED SOLUTION

Great advice Doug!



Christopher, in case you're wondering , one reason for using active instead of state in the queries is that the code will continue to work if you add additional values for state to indicate special closed states.   We've done this in our change record and it's a pain to locate and change all the business rules which refer to the state when you add a new value.


View solution in original post

3 REPLIES 3

randrews
Tera Guru

did you try doing an addORQuery for the state != 9 ??



although honestly a better way to do this would be to make sure your active/closed BR is working on change tasks.. and then just make the wait for querry if the task is active.


Great advice Doug!



Christopher, in case you're wondering , one reason for using active instead of state in the queries is that the code will continue to work if you add additional values for state to indicate special closed states.   We've done this in our change record and it's a pain to locate and change all the business rules which refer to the state when you add a new value.


Well the problem seemed to have been the state 9 was not a field that triggered the Business Rule "SNC - Run Parent Workflows" for us, so I created a new BR for change_tasks that included state 9 so that the workflow will update when the change task is cancelled.


I've also taken your recommendation to have the Wait for Condition check for Active instead and this seems to have taken care of the problem. Many Thanks for the suggestions