Category: Graphical workflow
Posted by Mark Stanger in Graphical workflow Monday, 16 August 2010 08:57 No Comments
A
common Graphical Workflow requirement in Service-now is to tell the workflow to wait for some trigger before continuing. The ‘Wait For condition’ activity is available out-of-box and is very simple to configure. Usually when working with Service Requests or Change Requests I am asked how you can set up the workflow to wait for completion of all associated tasks before closing the Request Item or Change Request ticket. This can be easily accomplished by using a script in your ‘Wait For condition’ activity to query for any associated tasks that are still marked as ‘Active’. If the task is marked as ‘Active’ then it hasn’t been closed yet and the workflow should wait for that closure. Here are some sample scripts that I’ve used before to wait for task completion on both Request Items and Change Requests.
Posted by Mark Stanger in Graphical workflow Tuesday, 12 January 2010 15:19 3 Comments
This post is written in response to a question I received from a reader about how to handle ad-hoc tasks when you’re using graphical workflow. I’m always open 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 ‘Ask The Guru‘ link to submit them. Thanks Ruth!
“The requirement is to add an extra task to a set of tasks defined in a graphical workflow once it is running AND have a way of specifying the order AND have the new tasks start automatically when its predecessor completes and start the next on when it completes.
In the days of execution/delivery plans I had done this using a rule which set the new predecessor/successor entries but can anyone advise how to approach it with workflow?”
Posted by Mark Stanger in Business rules, Graphical workflow Tuesday, 29 December 2009 05:55 7 Comments
S
ervice-now.com provides a very robust and simple way to manage your tasks and approvals (among other things) through its graphical workflow engine. It is very common to use graphical workflow to help facilitate some change management process within your organization. One common requirement in change management is to be able to cancel or close the change request at any time during the process. “Simple”, you say. “Just allow the user to change the value of the ‘State’ field to ‘Closed’.”
You would not be incorrect in saying something like that, but you would be forgetting about part of the problem with closing or canceling a change request or other task ticket. What if the attached workflow(s) still think that the change request and its associated tasks and approvals are still in progress? Should the attached workflow context(s) continue to run indefinitely? If your workflow doesn’t have a way to know about the completion of the change request then it will continue to run (or more likely just sit and be forgotten).
Posted by Mark Stanger in Business rules, Graphical workflow, UI actions Monday, 28 December 2009 07:41 1 Comment
W
hen implementing the Change management process in Service-now you’ll probably encounter a scenario where your entire change workflow (including all tasks and approvals) needs to be reset. The first option to consider (assuming you’re using the graphical workflow engine to manage the tasks and approvals) is the Rollback workflow activity. The rollback activity works great for a lot of scenarios, but what if you don’t have a defined point in the workflow where everything should be rolled back? What if the rollback (or reset) can happen at any point in time? There’s not really an easy way to handle this within the workflow itself since you would need to check for a rollback condition at an infinite number of places.
Recent Comments