"Create Task" workflow activity marked complete when Incident state is "Resolved"

ericfisch
Mega Contributor

I have a catalog item workflow that is utilizing the "Create Task" to create Incidents through the flow. "Wait for completion" is set to true. However, I need the activity to finish once the Incident is marked as "Resolved" rather than closed. I changed the Workflow Activity Definition to look for more than just the task becoming inactive, but the flow is still not progressing. Below is the updated code in the activity definition. Has anyone faced this challenge or have any insight as to what I may be doing wrong?


// The task has changed, see if the task is done
onUpdate: function() {
// check for completion
var gr = new GlideRecord('task');
if (!gr.get(activity.scratchpad.taskID)) {
executing.state = 'finished';
executing.result = 'deleted';
return;
}

if (!gr.active || (gr.state == 6)) {
executing.state = 'finished';
executing.result = gr.state;
}
},

2 REPLIES 2

mdwallick
Giga Contributor

You have half the solution. There's a second part that you're missing.

You need a business rule on the incident table that "notifies" your workflow that it's been updated.

OOB, the business rule "SNC - Run parent workflows" notifies any workflow contexts attached to a task's parent that the child task has been updated. That business rule only runs if the state changes to 3, 4 or 7 (closed complete, closed incomplete and closed skipped, respectively).

You can do two things here:

1.) add " || current.state.changesTo(6)" to the "SNC - Run parent workflows" business rule. This would make an incident getting resolved "update" the catalog item's workflow with it's new state. Of course, modifying this business rule would mean that you now "own" it.

2.) Make a copy of the "SNC - Run parent workflows" business rule and modify it such that it runs on the incident table, with a condition of "current.state.changesTo(6)" with the exact same script. This way, an incident getting resolved will move your workflow along, without you having to take ownership of any OOB objects.

Make sense?


ericfisch
Mega Contributor

I took the second approach in order to to avoid taking ownership of the OOB object, and it work liked a champ. Thanks!