Start and wait for sub-flow running for another record

[Joris Scharpff]

Hello,

I am trying to create a custom workflow activity that starts another workflow and should wait for that flow to complete. It is in that sense very similar to the parallel flow launcher activity, however the flow that is started does not act on the same records. The use-case here is that we have a set of (automated) standard changes, each guided by its own workflow, and we want to start these flows from within request flows. I am aware of two workarounds but I find neither to be good options:

1) Let the sub-flow modify the record of the parent flow that started it, e.g. through a 'u_subflow_complete' field. This is definitely not an acceptable solution because this would require us to add such an edit operation to every change flow and the sub-flow needs to know the parent record. Even more so, image the edits required if we later would want to support multiple parallel sub-flows ('u_subflow1_complete', 'u_subflow2_complete'? yuck!).

2) Use a loop in the parent flow with a gs.sleep(x) in it and keep monitoring the state of the sub flow. This is nearly acceptable, although the pull method of checking every x time would impose an additional burden on the system. When x is too small, we check too often and waste computing time. On the other hand, if x is too large, we may be   waiting a long time for the parent flow to detect the child flow's completion.

A better option would be to use a mechanic similar to that of the Parallel Flow Launcher and Workflow Coordinator, i.e. to wait for events from the sub-flow that its state has changed, but we cannot get this to work. Using startSubFlow on a different record than current causes the workflow engine to report a bad activity context. For example:

var change = new GlideRecord( 'change_request' );
change.insert( );
workflow.startSubFlow( flowId, change, {}, change.sys_id.toString( ) );

Results in the following log mesage: md=Run Flow : executing=-1 : event=execute was aborted - bad ActiveContext=Div - Test:e1da3f33376d26007d81f01643990e5a, current=wf_workflow_execution:adda3f33376d26007d81f01643990e56 (while the change is correctly inserted and its flow is listed).

We also tried to use the regular startFlow activity, but then the parent workflow gets no status updates from the child flow. Finally we found functions like registerListener and handleEvent but we have not been able to achieve our goal with those.

[Kalaiarasan Pus]

If I understand correctly, what you are trying to achieve is the expected out of box behavior of sub flows.

http://wiki.servicenow.com/index.php?title=Using_Subflows

http://wiki.servicenow.com/index.php?title=Subflow_Activities

[Joris Scharpff]

Thank you for pointing this option out, this is indeed very similar. However, our use-case uses a 'standard changes table' that, besides the workflow, specifies several other (template) values to set in the change. Nevertheless I think your option seems the better approach and we are going to rethink our model.

Thanks for the help.

EDIT: I tried this approach but now the sub-flow   remains stuck on the task it creates until I explicitly Nudge it. Have you also experienced this issue and/or found a way to resolve this? You can simply reproduce this by creating two flows, one calling the other, and the one acts as the sub-flow should contain one 'Create Task' activity that is set to 'Wait for completion'. Now when I close the task I expect first the sub-flow to continue and finish, after which the parent flow terminates. However, when I close the task, the sub-flow is not notified of the task's completion.

[Shawn Dowler]

I don't know if you're still having issues with this, but what's happening is that you don't have a business rule that nudges the parent workflow whenever changes to the child record are made. If you populate the Parent field and both records are tasks, then it should just work. If not, then you need a business rule like the one on task that checks for changes to the other record to update the related record's workflow. That will cause the subflow to get updated.

This is the link to the business rule "SNC - Run parent workflows" as an example:

https://<instance-name>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=98412b3d0a0a0b88652919d1ff714e1d