Posts Tagged ‘Change management’
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 UI actions Tuesday, 27 July 2010 10:42 No Comments
A
few months ago I wrote about copying change requests using a UI action. While that method works great, it does require you to specify each and every field and value that you want to populate into the new change request. If you’ve got a lot of fields to copy over then you might end up with a pretty big script and a lot of items to copy over. You also need to be aware of any new fields that get added after you create the script and make sure that they get copied if necessary.
The following method works in much the same way, but it copies by performing an insert against the current record (rather than starting from a brand new change record and supplying each value). Because of this, you’re concerned about overriding any of the values (such as start and end dates) that you don’t want to be copied over from the record you are copying. This method works better if you know you want to copy over all (or the majority) of the field values from a given change.
Posted by Mark Stanger in Business rules Monday, 21 June 2010 11:47 No Comments
C
hange management in Service-now includes the use of a parent ‘Change request’ ticket and (usually) the use of multiple ‘Change task’ tickets that can be assigned to separate groups or individuals to perform specific pieces of work. Because these change task tickets should factor into the overall plan for the parent change request, it often makes sense to take the expected start and end dates of change tasks into account when setting a planned start and end date for the parent change request. The purpose of this script is to allow you to automate the calculation of the planned start and end dates for the parent change request based on updates made to the child change tasks. Whenever an update is made to the expected start or end dates of a change task, this script will run and evaluate the start and/or end dates of the other change tasks for the same change request. The earliest start date and latest end date from the tasks are then populated as the overall planned start and end dates for the change request.
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?”
Recent Comments