Current in Advanced Reference Qualifiers

General No Comments »

The “Current” object in the context of Reference Qualifiers is an interesting object that can assist in delivering the filter you are looking for in a Reference Qualifier. This article describes how to work with this object.
Continue reading…»

A view on database views

General 3 Comments »

Database views in ServiceNow are somewhat limited, but with a bit of creativity you can still make good use of them. The two main uses of database views are: Reporting and (direct) Web Services.
This blog will try to list the options and limitations of ServiceNow database views by trying translate SQL statements to ServiceNow Database Views. Below you will find a number of Information Requirements that you could have and the technical way to deliver this information. Goal is to show a technical concept where Database Views together with Before Query Business Rules provide a much more powerful solution that Database Views alone.
Continue reading…»

Dynamic SOAP Endpoints in ServiceNow

General No Comments »


One of the challenges when creating a SOAP interface is to make sure that each ServiceNow environment communicates with the correct environment on “the other side”. This article provides a fairly simple but effective way to make sure that after committing an update set that contains an update on an outbound SOAP Message or a Clone the outbound messages will still go to the correct instance.
In this example I will use properties to store the external endpoints, but you could also consider a table to store that data.

Continue reading…»

Sample Custom Incident SOAP Interface

General No Comments »

This article describes a sample setup of an Incident interface using the SOAP protocol between ServiceNow and an external system. It aims to deliver an interface that can easily be monitored by any user with access to the Incident Management module and it will also hand you some important considerations to take into account while designing the interface.

Functional Setup

We are looking at a situation where two systems interface Incidents. Both systems will play a role in the Incident Management process, which means that inserts and updates can be created on either side. Goals of an interface should be:

  • The Incident Process on both sides must be supported
  • Minimum manual work
  • The Incident Process on both sides should be respected. This means that expecting once side to change its process to support the process on the other side should be prevented. This also goes for Codings such as Status and Categorization
  • Data consistency must be preserved: at each moment the data in both systems must match
  • It must be possible to monitor the interface


The first step in creating an interface is to look at the process on both sides and to find a logical flow across both systems. Main questions will be:
Continue reading…»

Script Include – helps you prevent duplicate work and keep your desk clean

General No Comments »

Any developer knows the feeling “I think I have done this before, but where is this code?”
In this short article I would like to show some (obvious) advantages of using Script Includes to their fullest.
There are several reasons to move as much server side code as possible to Script Includes.
First of all Script Includes are accessible from any other server side code, and secondly they will only be accessed whenever they are actually needed (which prevents unnecessary checks in Business Rules that will not run anyway).
Recommendation is to set up a script include for every table that has any custom methods.
Depending on the exact setup, you can decide what your initialization should look like:

Name: CustomTableUtilsClass
Description: Class that contains methods that may be used on several occasions
[cc lang=”javascript”]
var CustomTableUtilsClass=Class.create();

// initialize your class.
initialize: function(gr){
// the parameters that you define here, depend on requirement.
// you can pass the GlideRecord,
// or just the sys_id of the current record.
// if the methods have nothing to do with “CustomTable”,
// then it may be wise(r) to define the functions
// in a separate Script Include

// declare the functions that are available for the developer
Functionality1: function(){
var sResult=this._doStuffWith(this.curRecord);
return sResult;

// set up some assisting functions
var sClass=gRecord.getClassDisplayValue();
return sClass;

type: CustomTableUtilsClass

So far pretty straight forward, right?
Continue reading…»

Change the class of a CI

General 5 Comments »

Sometimes you may find that a CI is in a wrong class, and you need to move it to another class.
Obviously you can delete the CI and recreate it using the correct class, but if you want to preserve relationships (to Tasks or other CI’s), this may not be an option.


There are two methods that can be used to accomplish this, both with the same results:

  1. Add the Class field to the CI form, and update the class to the desired class
  2. Create a script that updates the sys_class_name field of the CI specified to the new class name

Other methods – mentioned below – do NOT work:
Continue reading…»

Sharing Sections across Forms

General No Comments »

If a customer uses a lot of different forms for one extended table (for instance cmdb_ci), it is possible to share sections across these forms.
The instructions below describe how to set this up.

Please remember: when you create an extended table, the layout of this table will be an exact copy of its parent. As long as you don’t change anything on the form layout, this will remain the case. By following the steps below, you force the system to create a separate instance for that form, so any modifications to the parent will not be propagated to the extensions anymore.

Step 1: Create table if needed.

Step 2: Create the section you need to share.
Do this at the highest level that contains all the attributes.
This is needed because the section will only be available for the extensions of the form where you created it.

Top left, in the Application Navigator header, type “” to get to the Configuration Item form.

Create a new Section (Personalize -> Form Layout) “CI Relationships”:

Add the CI Relations and Save the section:

(steps 2 and 3 are there to make sure your main section doesn’t disappear when executing this action)

Continue reading…»

Attribute Inheritance in CI Classes

General No Comments »

Sometimes it is important to understand the impact of a CI in the big service delivery picture. In such a case you could investigate all CI´s that are affected by this CI, but it is also possible to summarize this impact into a number of attributes, such as SoX relevance and Security Level.

In this article I will show a relatively simple concept of making sure that these attributes are inherited and calculated from the parents to their children (and in turn to their children… etc).

The setup used in this example is as follows:

  • A customer has several Applications in his CMDB.
  • Each of these applications has a number of instances (for instance Production, Development, etc).
  • Each of these Application Instances is supported by one or more Servers.
  • Each Server supports one or more Application Instances.
  • Each Server also resides in one Data Center.

The goal of this exercise is to make sure that – at any time – you know if a certain Server or Data Center is supporting a SoX compliant Application Instance and what the maximum Security Level (0, 1, 2, 3, 4 or 5) of the supported Application Instances is.
Continue reading…»