Wait for condition and multiple paths normal change wf not working as expected

[emyrold]

I am trying to add some alternate paths to the Normal Change workflow to be able to move through the change state model without too much customization.

Requirement:

- (a) Workflow should process normally if people click the OOB UI actions that move the change along the normal state model.

- (b) If there are multiple manually created change_tasks, when the last task is moved into one of the three closed states it should:

  - if change_request is not already in 'implement' it should set the change_request to implement, then set the change request to 'review';

  - if change_request is already sitting at 'implement', it should then just move it to 'review.

First attempt was to create a BR on change_task to do this and got it working my using a script in a wait for condition activity.   However, we have been asked to keep it in the workflow.

2nd attempt was to start branching the workflow to account for both path (a) the normal OOB path and path (b) where we automatically increment the states along the state model path when last change task closes.

I'm attaching a screen shot of how I think it should be working, when process a change request and manually close the last change_task it appears to branch correctly, however when it transitions to set to review there is a Debug statement saying it cannot transition from 'scheduled' directly to 'review'.   The issue is one of the proceeding activities is to set the change request to implement first and it transitions through this activity and then transitions through the wait for Implement activity and then sets review.

not sure if there is a timing issue or I need to add explicit joins but cannot figure out how to structure this workflow to accomplish both paths using wf activities only.

Thanks,

-e

[oharel]

Hi Erik,

Thanks for the flow scenarios. So now back to the beginning (yes, I'm a bit slow...): Which of the above scenarios causes an issue?

harel

[emyrold]

OK, so to simplify we only need to focus on one scenario/path and once that works, I'm sure the others will work.

In the case where I create a change_request with no change_tasks, process approvals so it lands in 'Scheduled' the workflow branches to 1. the wait for tasks to close and 2. join.   The workflow stays on these two executing activities and will not transition to the next.   I have added workflow logging and when I go into the workflow context of a test record and click nudge it will log my log statement correctly.   It just will not transition to the next activity after the join.

Here is an updated screen shot and code for the wait for script.   I have added more explicit branch'ing and join'ing in the workflow to make it more clear.

var gr1 = new GlideRecord('change_task');
gr1.addQuery('change_request',current.sys_id);
gr1.query();


if (gr1.getRowCount() > 0) {

// I have change tasks
var gr2 = new GlideRecord('change_task');
gr2.addQuery('change_request',current.sys_id);
gr2.addActiveQuery();
gr2.query();

// all tasks closed move to review
if(!gr2.hasNext()) {

answer = true;
workflow.info('in gr2.hasNext answer is: ' + answer);
}
else{
//Tasks are still open

answer = false;
workflow.info('in gr2.hasNext else answer is: ' + answer);
}
}
else {
// I have no tasks

answer = false;
workflow.info('in no tasks answer is: ' + answer);
}

[oharel · Accepted solution]

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

[emyrold]

Hi Harel,

Again, thanks for taking so much time to review this with me, really appreciate it!

So I think I's seeing your point about the last join.   I just have very specific requirements that I wish I did not have, would make it a lot easier.   The fact is I have not even tested the second join path so not sure if my logic is fully correct.   I think I did that second join to handle the case what if there are open tasks and the Change Owner decides to move the CR into Review.   The thought being if they feel the change is complete and want to move it to review they can without forcing them to close the child task.   If I cannot get that logic to work, then I will just say, if you have an open change task and you want to move to review you will need to close it.   I guess I could customize the Review UI Action to close change tasks but trying not to customize those OOB objects.

Also, I've read on the wait for wiki that if the wait for is looking for something that is changed in the workflow e.g. 'Set Values' and there is a wait for following, you will need to drop in a 1 second timer....     for now, I'll pull out the second join and just try to get the more simplified version you just gave and see if I can get it to work.   Right now, it just gets stuck after the first branch and even a nudge will not move it into the wait for implement activity.

Will update shortly, thanks!

[emyrold]

Hi Harel,

This is working now. My wait for script needs to not move forward when users process a change request with no tasks with the branch.

Currently this allows them to move the change request to review even with open tasks. If they change the requirement and want to prevent this, then I can remove the branch, reorder things a little and add a some sort of client side message about closing the open tasks first.

Thanks for all your help!

-e

answer = doit();


function doit() {
var gr1 = new GlideRecord('change_task');
gr1.addQuery('change_request',current.sys_id);
gr1.query();

// I have change tasks
if (gr1.getRowCount() > 0) {
var gr2 = new GlideRecord('change_task');
gr2.addQuery('change_request',current.sys_id);
gr2.addActiveQuery();
gr2.query();

// all tasks closed move to review
if(!gr2.hasNext()) {
return true;

}
//Tasks are still open
else{
return false;

}
}
// I have no tasks
else {
return false;

}
}

And workflow: