This postal service is written in response to a question I received from a reader virtually how to handle ad-hoc tasks when yous're using graphical workflow. I'chiliad always open up to suggestions on how to improve the site and its content. If you have any ideas, questions, or suggestions for the site just use the Contact link to submit them. Cheers Ruth!

"The requirement is to add an extra task to a set of tasks defined in a graphical workflow in one case it is running AND have a manner of specifying the order AND accept the new tasks start automatically when its predecessor completes and commencement the next ane when information technology completes. In the days of execution/delivery plans I had washed this using a rule which set the new predecessor/successor entries but can anyone advise how to approach information technology with workflow?"

This isn't an easy problem to solve. I still don't know if I've establish a actually skilful way to approach it all the same, merely hither are a couple of things I've washed in the past (that are currently being used in production systems) that may give you some ideas. Take it for what it's worth. These probably aren't perfect solutions, simply it's better than nothing I suppose! I'd honey to hear of any feedback you accept equally y'all try these out (if you do) because this is an issue that I'm probably going to have to tackle in some other month or so over again.

Option #i:

Using execution plans and a custom business rule to allow insertion and re-ordering of tasks after the execution plan has initially been attached.–
What I've found is that execution plans are still more forgiving when it comes to ad-hoc tasks than workflow is. Because of this, if you lot have a demand for ad-hoc tasks in Change requests, I think it makes a lot of sense to split up the workflow processing and use Graphical workflow for approvals, and use Execution plans for task generation. If there's no demand for advert-hoc tasks, then I retrieve Graphical workflow works all-time.

The challenge with ad-hoc tasks is the sequencing of those tasks. This business organization rule basically re-orders the entire listing of associated alter tasks in the execution plan each time the club on a change chore changes. This includes when a new job is inserted.

-Table: Change task
-Order: 100
-Runs after insert/update
-Status: current.order.changes()

syncTaskOrder( ) ;

function syncTaskOrder( ) {
//Query for all tasks that are associated to the same parent
var rec = new GlideRecord( 'change_task' ) ;
rec.addQuery ( 'parent' , electric current.parent ) ;
rec.orderBy ( 'order' ) ;
rec.query ( ) ;
while(rec.next ( ) ) {
//Delete all of the existing successor/predecessor records for the task
var rec1 = new GlideRecord( 'execution_plan_local' ) ;
var qc = rec1.addQuery ( 'predecessor' , rec.sys_id ) ;
qc.addOrCondition ( 'successor' , rec.sys_id ) ;
rec1.query ( ) ;
while(rec1.next ( ) ) {
rec1.deleteRecord ( ) ;
}
}

//Query for all tasks that are associated to the same parent
var tsk = new GlideRecord(current.sys_class_name ) ;
tsk.addQuery ( 'parent' , current.parent ) ;
tsk.orderBy ( 'gild' ) ;
tsk.query ( ) ;
var lastID = '' ;
var lastOrder;
var myIDArray= new Assortment ( ) ;
while(tsk.next ( ) ) {
if (tsk.order > lastOrder) {
//Iterate through the sys_id assortment and create a new successor/predecessor record for each item
for (x in myIDArray) {
//Initialize the creation of a new Task Sequencing record
var tsk1 = new GlideRecord( 'execution_plan_local' ) ;
tsk1.initialize ( ) ;
tsk1.predecessor = myIDArray[ten] ;
tsk1.successor = tsk.sys_id ;
tsk1.insert ( ) ;
}
//Empty the existing array
myIDArray.length = 0 ;
//Populate the electric current task sys_id into the array
myIDArray[ 0 ] = tsk.sys_id.toString ( ) ;
}
else if ( (tsk.order == lastOrder) || !lastOrder) {
var myIDArrayLength = myIDArray.length ;
if (myIDArrayLength > 0 ) {
//Get the last item in the array
var arrayIDVal = myIDArray[myIDArrayLength - 1 ] ;
//Query the Task Sequencing table for that item
var ps = new GlideRecord( 'execution_plan_local' ) ;
ps.addQuery ( 'successor' , arrayIDVal) ;
ps.query ( ) ;
while(ps.next ( ) ) {
//Create a new successor/predecessor tape for the current task
var ps1 = new GlideRecord( 'execution_plan_local' ) ;
ps1.initialize ( ) ;
ps1.predecessor = ps.predecessor ;
ps1.successor = tsk.sys_id ;
ps1.insert ( ) ;
}
}
//Populate the current job sys_id into the array
myIDArray[myIDArrayLength] = tsk.sys_id.toString ( ) ;
}
else {
}
lastOrder = Math.round (tsk.club ) ;
lastID = tsk.sys_id.toString ( ) ;
}
}

I also had to include this business rule to go the orders on the tasks to sync with execution plan chore orders initially (although this may have been a problems that has since been fixed and then this one may be optional).

-Table: Change task
-Society: 1,100 – This is important!
-Runs before insert
-Condition: current.delivery_task != "

electric current.guild = electric current.delivery_task.club ;

I suppose the to a higher place method could also be used with Service requests, but I haven't tried it.

Selection #2:

I've seen this pick used for service requests in ServiceNow. You tin fix 'dummy' service request items that can exist added to a service asking with a defined number and ordering of tasks. This method could be used with either Graphical workflow or Execution plans.

The client that used this method (like well-nigh other customers) didn't have a divers Service catalog, but wanted to use our Service catalog anyway. Basically what they concluded up doing was having a single generic Service catalog item with a couple of steps that got added to any service request. And then they allowed their technicians to add together other pre-defined request items to the request on the back cease using the 'Add new item' button on the Request form. They defined as much equally they could, but they besides had pre-defined items that had tasks associated with them like 'One task item', 'Three job item', etc.
The nice matter about this method is that you can still adhere your workflow or execution programme directly to those items. The person who needs to add together more tasks can only add another particular to the request and it already has its workflow associated with information technology.

Option #3:

Create sub-tasks that tin can be manually added to the generated modify or catalog tasks. Here is an case of how you could handle this for alter requests. Let's say that all of your change requests have to go through the same 3 steps. However, in sure cases, ane or more ad-hoc tasks are needed. You could ready an execution plan (or workflow) to create three change tasks, and and so create another table called 'subtask' that could exist manually added to each auto-generated change task as necessary like this…

*Change Request
*Change task ane –> FROM EXECUTION Program
*Subtask 1 –> MANUALLY ADDED
*Subtask two –> MANUALLY ADDED
*Change task 2 –> FROM EXECUTION PLAN
*Change task 3 –> FROM EXECUTION PLAN

And then Subtasks 1 and 2 are children of Change job 1, and alter task i does non get closed until subtasks 1 and 2 are closed.

Option #iv:

Use a script in a 'Wait for' activeness in your workflow to query for associated tasks and await for their completion before moving on. This approach doesn't deal with the ordering direct, simply it does allow you to command tasks that are added exterior of the workflow scope. The full solution is documented here in the Service-now wiki.