Service Catalog requested future delivery date and starting tasks on specified date

General Add comments

The Catalog
In a fully automated Self Services system, a customer is able to order services or products via a self-service portal. The items that can be requested are often offered via use of an actionable electronic service catalog. When the customer enters an order, the system automatically picks it up and starts the execution/delivery for the request. Responsible delivery groups get notified that are all part of the delivery chain. Group response- and progress time is also monitored according to defined Service Level Agreements (SLA). Usually, SLA’s are defined using the Service Level Management process at the definition stage of a service or product. The agreements are translated into automated monitoring rules and get accordingly implemented in ServiceNow. Once requests are made available using the Service Catalog, automatic ordering can be handled nice and smoothly.

But what if the customer would like to order now, but the delivery is allowed to wait for some time, since there is no high priority?

In such a case you would like to prevent waste of time, where effort(s) could have been spent on other activities that might have a higher priority. Secondly, it might also work as a money-saver, since it prevents risk of service breaching due to an SLA. Knowledge about the customer-expected delivery date can also be an effective means for delivery group capacity planning. This could prevent capacity-bottlenecks at request peak-time(s) where delivery groups might not be able to handle such request workload. It would be nice if capacity-planning could (allowed to) be planned upfront where it allows to be spread over a broader timespan without a necessity for e.g. temporary workers.

Perhaps the solution described below can solve this issue….

The functional description is as follows:

  • When a customer wants to request an item using the Service Catalog, the ability to specify a preferred delivery date known as the Requested Date field is introduced. This date should always only allowed to be a future date. The logic for this is specified as follows: if the Requested Date lies before the SLA due date, then the requested date is regarded to be a wish date. No rights can be derived out from the wish date. If the Requested Date lies after the SLA due date, then the SLA should be paused. The requested item shouldn’t breach the SLA in case the demand gets fulfilled (requested date in the future compared to the normal SLA due date). Once the Request date is reached the SLA should be reactivated.

When looking at the ordering process, roughly the following steps are in scope:

  1. The ordering step, handled by the customer when ordering either a service or product from the Service Catalog and submitting the request.
  2. Then a request is generated that contains all customer requested items.
  3. Finally, a delivery workflow associated with the requested items is triggered that starts a couple of catalog tasks. These tasks get assigned to the responsible service/product delivery.

Now onto the technical part of the solution; how to facilitate this in ServiceNow….

During the ordering step, when the customer enters the ordering information, the (additional field) Requested Date should be made available.

Click for full size in new window/tab

Figure 1: Ordering a catalog item

The Requested Date field allows the customer to specify a later date. By default the Requested Date field contains the SLA due date – as stated/agreed in the SLA. After submitting the request, all related request item(s) as described in step 2 get generated too. In our example we’re referring to request REQ52379 which only holds 1 request item (RITM53106) and 1 catalog task (TASK45634). Now, for each item a delivery workflow is started – in our example there is only one – where the workflow generates the first catalog task. Because of the preferred Requested Date that holds a far-future date, further in future than to the data stated in the SLA definition, the catalog task is immediately set to a pending state.

Click for full size in new window/tab

Figure 2: Set catalog task to state Pending


This also applies to the linked Requested Item and the SLA linked to it set to paused (GEN REQ SRv 5D0H0m [5|Mo-Fr 0800-1800|NL].

Click for full size in new window/tab

Figure 3: Set Pending state of Requested Item and pause the SLA

This is handled by a Business Rule that gets triggered at catalog task creation and when the SLA due date gets calculated. In addition, the Business Rule creates a scheduled job that runs at the customer Requested Date which updates the catalog task to an Active state and – in turn – reactivates the SLA as well.
The Business Rule definition is provided below.

Click for full size in new window/tab

//execute only when requested date > sla date
if(current.request_item.sla_due < current.variable_pool.requested_by_date ){
    var datetime = gs.nowDateTime().split(‘ ‘);
    current.state = 50; // Set task state on Pending
    current.u_pending_reason = ‘4’; // Set pending reason
// Create Scheduled Job to reactivate cataog task
    CrtTskJB(‘Activation job task ‘ + current.number, current.variable_pool.requested_by_date + ” ” + datetime[1], current.sys_id);

function CrtTskJB(SCTNAME, JBDATE, ID){
    //Create a trigger
    var newTrigger = new GlideRecord(“sys_trigger”); = SCTNAME;
    newTrigger.next_action = JBDATE;
    newTrigger.document = ‘sc_task’;
    newTrigger.document_key = ID;
//Activation script which is run by the scheduled job (see example below of scheduled job)
    newTrigger.script = “var tsk = new GlideRecord(‘sc_task’); tsk.addQuery(‘sys_id’, ‘” + ID + “‘); tsk.query(); if ( { tsk.state = 30; tsk.update();}”;
    newTrigger.job_id = ’81c92ce9c0a8016400e5f0d2f784ea78’; //Set “RunScriptJob”
    newTrigger.trigger_type = ‘0’;
    newTrigger.log = true;


Click for full size in new window/tab

Figure 4: Scheduled job that activates the Catalog task

The above provided scenario facilitates a Service Catalog request holding a future request date that is specified by the requesting customer and which is relatively simple to implement.

If you have any question, please don’t hesitate to contact me on

Leave a Reply