Workflow not responding to task update

[Suzanne_Ryan]

I have a catalog item that creates a RITM and TASK and, depending on the disposition of the task, may or may not require that a Change be created.    

I've added the UI Action for "Create Change" to the right click menu, and this does work, but I really don't want this ability available for all requests, and I'd actually like to work the change creation from the workflow, where I can send specific information to the change and assign it automatically.

There's a variable on the form "Create Change?" Yes/No/None.   I tried an "IF" and a "Wait For Condition" in the workflow, but neither one responds to the update of this variable on the task.  

The issue may be that the RITM and TASK are created by one person, and later updated by someone else (where the Create Change variable may or may not be updated).     It appears that the workflow doesn't see the update to the Task.

Here's the script for the If and the Wait for Condition.   It's OOB.   It doesn't trigger the Create Change task when I check the box and update the form.     Of course, if I simply modify this to say "answer = true" the workflow progresses as I want it to, but the needed condition is not addressed.

answer = ifScript();

function ifScript() {

      if (current.variable_pool.ccb_changecreate == 'true' ) {

            return 'true';

    }

      return 'false';

}

Any ideas?

[randrews]

that does clear things up and i have a few questions...

1> after you set the change required variable to yes... if you update the item.. just add a comment and save it does the workflow kick off the wait for?

2> how is your workflow ever going to exit if the item doesn't require a change? it looks to me like those would be stuck waiting at the is a change required wait for forever.

if i am reading your intentions correctly the yes/no variable should ONLY be checked when the task for "create catalog task" is closed... if so you wont' need a wait for really just set the variable and close the task then put an if then after the task....

if this is NOT true and we don't want to only check if the first task is closed.. you will need to branch before that taks.. one branch going to the if then.. and the other going to the catalog task in parallel.

[Suzanne_Ryan]

Hi Doug, thanks for your response.

1.   Just tried that, no joy.

2.   Right--that's why I vacillate between an if/then and a wait for condition.   I believe that once I can get the update to work I'll be able to work out the "Change not needed" branch.    

So, my intention is a little different that what you're thinking.   The Catalog Task can remain open indefinitely.   The creation of the Change Request is not tied to the closing of the task.   The Catalog Task is there to document changes to enterprise applications and it's reviewed several times by a CCB (including after the formal Change Request is closed).   Once the change to the application is approved by the CCB (another variable--not the normal approval process), the box is ticked for the official Change Request to be created.   One factor in this is that the request/task are created by SME's and the change can only be done by IT (that's part of our configuration of SN).  

I'll give the Branch a try and see if that helps.

[randrews]

ok that is what i was afraid of.. with a linear workflow like that the wait for will ONLY be invoked when the task is closed.. what you want to do is put a branch in front of the task.. then from the branch go to both the wait for and the task..

that will solve the first part of the problem.. we don't want to use an if/then because that will only test it immediately we want it to keep checking the record...

it is HIGHLY likely that with them in parallel the workflow won't kick the wait for until the item record is updated... if so you can try the resume workflow trick.. or a very simple solution.. add an onchange client script on the task that is set for the onchange checkbox... when it is set update the parent with a note of "A change is required for this item" or something similar... simply updating the item will make the workflow check the workflow and spike it to run... it will also provide documentation at the item level of when the change variable was set and <if you want> who set it.

ohh yeahh one more thing make sure you bring the parallel branches together in a join or the workflow will chug right along even though the first task isn't closed!!

[Suzanne_Ryan]

Got it.   Didn't even think of the onchange script.   Brilliant. I'll work this and let you know how it goes.   Thank you!

[Suzanne_Ryan · Accepted solution]

Wanted to post the resolution for this item.   After continuing to work this I came up with a very clunky solution--to have the workflow create a task, which, when closed, would trigger the create of the change.     Works, but oh so awkward.   In thinking about this and brainstorming with a colleague, we came up with using the approval process.    

This is working really well, to the point of automatically closing the RITM when the Change is closed.     Super simple, works great.   I took off the checkbox for "Wait for Completion" on the Task.