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

emyrold · ‎10-18-2017

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 · ‎10-21-2017

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

View solution in original post

oharel · ‎10-19-2017

Hi Erik,

I am not sure why you're doing it this way. So please explain again:

If I understand correctly, the 1 and 2 are necessary because users can open manual tasks and you want to make sure they are closed before moving on to Review.

Why do you need Wait for Condition 3? You already set the state in 4.

My question is why not skip 3 entirely and go from Scheduled to 1 -> 4 -> 2 and to Review from there? (What might happen between setting the state to scheduled and 3?)

harel

emyrold · ‎10-19-2017

1 -> 3 cover the case If they click the the 'Implement" UI action (changing state to Implement) on the change request (which may or may not have change tasks).

oharel · ‎10-19-2017

So two scenarios:

1. the cr is in Scheduled, and then there are some tasks open, so we are waiting for 1. When 1 is fulfilled the wf will move to 1 and then to 3 and then directly to Review.

2. the cr is in Scheduled, the customer clicks on Implement, the wf moves 3, checks for 2 but also moves to Review. Is that what you wanted to achieve? because if yes, then 2 seems irrelevant.

By the way, maybe you can hide the UI action "Implement" until all tasks are closed. Then either show it or move the request automatically to Implement state (using 1). That would make the request more linear: Scheduled > 1 > 3 > Review

harel

emyrold · ‎10-19-2017

actually my 1 -> 3 use case was worded incorrectly it really should have been 0 (moved to scheduled) -> 3 -> 5 ( Review)

so here are the paths and the use case that they are trying to solve for.

0 -> 3 -> 5:

- Change Request with no child tasks (has UI Actions and editable state field with only the relavent next state choices)

0 -> 1 -> 4 -> 3 -> 5:

- Change Request with child tasks and the implementer closes the last task, have to change state to Implement first then Review. OOB BRs block from going from schedule directly to Review.

0 -> 3 -> 2 -> 5:

- Change Request with child tasks where the change owner does move the change request to implement via UI action or changing the state choice. But and have to wait for the last change task to be closed.