Sunday, Sep 05, 2010
Login

Posts Tagged ‘Graphical workflow’

Managing Ad-hoc Tasks in Service-now Workflow

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?”


Parsing the Date and Time Sections from a Date/Time field

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);
    }
  }
}

Canceling executing workflows on task closure

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).


Reset change request workflow, approvals, and tasks

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

  • Scott Stechmesser: Awesome script to use. Works great. How would you modify it to be able to copy a Catalog UI Policy?
  • Tulio: Perfect!!! Thanks for this.
  • Ron Methias: Another reason why I have stopped going to the official SN documentation sites and make the GURU my...
  • Richard Huss: Ingenious – and somewhat simpler than the way the Incident Resolution best practice plugin does...
  • valor: Joe, that’s one of the reasons why I’m parsing out the URL instead of trying to get the page...