Option 3 assumes you create a sub-task table that sits under ‘change_task’ or something similar. Your workflow wouldn’t be involved with the sub-task records at all. Users would simply associate the sub-task records to change task records as needed via a related list or something similar.

Hi. You’ve basically got 2 options. The first is to use a ‘Script’ or ‘Wait for’ activity to query for the tasks and pull back the necessary information. That way might be a bit more difficult but it’s the best way to integrate with your workflow. The second way is to set some attribute on your parent record from the workflow and then have a business rule that updates the corresponding tickets. Either way, it’s a challenge unless you’ve got some consistent attributes on your tasks (perhaps forced by a template or order).

Basically the question is how do I get both methods to talk to each other through the progression of the ticket?

For our Change module, we needed a workflow that would be completely open when it came to change tasks. So we built buttons for moving changes from Stage to Stage. Also some custom BRs at ‘implementation’ step to check for any pending change tasks and start the first one(s) by switching their state to Open instead of Pending. When each change task is closed, it checks to see if there’s another child of the same parent that needs to be switched on and switches on the one(s) with the smallest order number. At the moment we have no restrictions on when change tasks are allowed to be closed (you can have a task that involves prep work as opposed to implementation), but it’s easy enough to build a check into a UI action to query the open tasks and make a decision based on that. Anyway, none of our change tasks appear in our Change workflow, it’s all done with BRs. It’s up to the humans to build all the tasks and set their orders appropriately, of course. No auto reordering or anything. But we do allow list edit on this field, so it’s simple to reorder stuff in the related list shown at the bottom of the change record. So far it seems to be working, though I have a few pending requests to tweak it. :)

It’s never a bad idea to request an enhancement to the product. In some cases (like this) the enhancement has already been requested, but the more people ask for it, the more likely it is to get the attention of Service-now developers.

Thanks so much for this. Option 1 is the the way I have done it when using an execution (delivery) plan but it is good to know what we have done is the same as the guru’s!

I think your option 3 sounds the most promising as it looks as though it could co-exist quite nicely with the graphical workflow and we will investigate that.

Do you reckon it could be worthwhile asking for an enhancement in this area (e.g. an option to allow the order field on a task to be used to control this)?

Thanks, Ruth