Posts Tagged ‘Graphical workflow’
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?”
H
ere are some examples of how you could use a simple Javascript ‘split’ method to parse out the date and/or time value from a date/time field. Both examples split out the date and time, populate them into variables, and then populate the date section into a regular date field on the same record.
Business rule example:
This could also be used in a graphical workflow ‘Run script’ activity but would need to include ‘current.update()’ at the end to call the update to the record.
Name: Populate Date from Date/Time
When: Before
Update: True
Condition: current.u_start_date_time.changes()
var dateSection = current.u_start_date_time.split(" ")[0]; //Gets the Date
var timeSection = current.u_start_date_time.split(" ")[1]; //Gets the Time
//Set the value of the Date field with the date from the Date/Time field
current.u_start_date = dateSection;
Client script example:
As is the case with all client scripting in Service-now, all fields referenced must actually be part of the rendered form (though they may be invisible) to be referenced by the client-side script.
Name: Populate Date from Date/Time
Type: OnChange
Field name: Start date/time (or whatever your date/time field is named)
function onChange(control, oldValue, newValue, isLoading) {
//If the page isn't loading
if (!isLoading) {
//If the new value isn't blank
if(newValue != '') {
var dateSection = g_form.getValue('u_start_date_time').split(" ")[0]; //Gets the Date
var timeSection = g_form.getValue('u_start_date_time').split(" ")[1]; //Gets the Time
//Set the value of the Date field with the date from the Date/Time field
g_form.setValue('u_start_date', dateSection);
}
}
}
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