Using script to start subflow?

DrewW
Mega Sage
Mega Sage

Has anyone used a script to start a subflow?   We have a catalog item that is for new software and it has a bunch of check boxes that are for the software the user would like access to.   Each one has its own workflow.   So what I was thinking is rather than have 60+ "If" activities to check the var's I would just use a script.   Just wondering if anyone has done this before and what issues they have found.   We do want the item to stay open until all of the workflows complete.

1 ACCEPTED SOLUTION

russ_sarbora
ServiceNow Employee
ServiceNow Employee

The Parallel Flow Launcher activity introduced in Fuji is intended to solve this problem. It allows you to start any number of dynamic subflows.


View solution in original post

9 REPLIES 9

I have some workflows that call an approval subworkflow and use a script to set the values passed to it.


find_real_file.png



The script is used to set the scratchpad settings


workflow.scratchpad.out_xxx = <a value>


and so on



the sub workflow is set to require some workflow inputs


when added I just pass the relevant information from the scratchpad over



find_real_file.png



The subworkflow takes the values and processes as needed and returns a value to the field assigned above



If running the same workflow in parallel, I will use workflow,out_xxx; workflow_out2_xxx; workflow_out3_xxx; and so on and make each subworkflow use the relevant scratchpad values.


I also add a 5 second time before each parallel branch as I found it was not running correctly without the minimal delay



find_real_file.png



Cheers


Thanks for the reply, but what I'm looking for is to dynamically decide what workflow to start so if they want 10 out of 60 pices of software I just run a single script that decides which 10 workflows to start and what parameters they need, set them up and start them.   Making it static is something that I want to try and avoid because tomorrow it may be 85 software selections and the day after that it may drop to 50.   So far it has only changed by 1 or 2 per month but still having to update the workflow that much is something I'm trying to dodge.   The workflow also starts getting REALLY messy with all of the "IF" activities.



Your screen shot gave my an idea about where I may find some code for creating my own activity using the "Workflow" activity and I just found that after upgrading to Fuji there is a new activity called "Parallel Flow Launcher" that looks like it will do what I want.


The above is dynamic in that the sub workflow is the same and the scripts above determine what values are being passed to the subworkflow where it then runs its own routines to determine what approvals are required.



If not I would look at what Kenneth put as that will allow you to call whatever workflow(s) you like



I do know what you mean about a workflow with too many if statements. We have one here that was written by a 3rd party and is a nightmare when it goes wrong or needs changing.


We did modify some parts during various updates to use approval groups opposed to named approvers that made it easier. the next change will see if move to using a version of the workflow that uses this sub workflow method.


You can create all those different workflows and set a condition on their start, instead of invoking those workflows directly from another workflow or a script.



For example, if you were to create a catalog task for each piece of software, and the software was the associated CI (or choice value, or whatever), then you can create a workflow that has a condition that the CTask lists a particular CI (or certain CIs if they share the workflow). Then that workflow will run, and when it finishes you can have it close the task.



Then the parent request will eventually detect that the CTasks are all closed, and your main workflow can move on if you'd set it to wait for closure.



I'd prefer this way since it has smaller pieces, instead of one godflow directly interacting with dozens of possible subflows -- the pieces can be independently managed and debugged.   Also, I've had issues with Rollback or Restart usage for workflows using subflows (the subflow gets a duplicate and they both run in parallel, not sure if this is intended behavior that needs to be accounted for or a bug).


russ_sarbora
ServiceNow Employee
ServiceNow Employee

The Parallel Flow Launcher activity introduced in Fuji is intended to solve this problem. It allows you to start any number of dynamic subflows.