Sample code to get the catalog variables in the ServiceNow workflow

var gr  = current ;
var firstName  = gr.variables['first_name'] ;
var lastName  = gr.variables['last_name'] ;

var fullName  = lastName.getGlideObject().getValue() + " " + firstName.getGlideObject().getValue() ; 

Sample code to restart servicenow workflow

var gr = new GlideRecord('sc_req_item');
gr.addQuery('number', 'RITM0106387');
gr.query();
if(gr.next()) {
var w = new Workflow();
         var context = w.startFlow('67755686db2c4b004620d2c75e96191e', gr, 'insert', '');
}

Catalog client scripts and catalog UI Policies on ServiceNow Order Guides

By default catalog client scripts and catalog UI policies are not visible on the form, they can be added from the related lists section 

What happens to the currently running workflow if new changes are made to the workflow

Once a record triggers a workflow, it keeps the original context version through the life of the flow. Only new workflow contexts created after you publish the change will use the new flow.


When a new version of an existing workflow is published, the changes are not applied to running workflow contexts. Any currently running workflow context continues using the workflow version that was available when the workflow started. The next time the workflow runs, it uses the updated, published version.

Auto close standard change/incidents after 5 days

The following script can be schedule to auto close the standard changes/incidents after 5 days to auto close



var changeGR = new GlideRecord('change_request');
changeGR.addQuery('type', 'Standard');
changeGR.addQuery('state', 0);
changeGR.query();
while(changeGR.next()) {
var dif = gs.calDateDiff(changeGR.sys_updated_on, gs.nowDateTime(), true);
gs.print(changeGR.number);
if(dif >= 5*86400){
         changeGR.state = 3;
         changeGR.comments = 'Change Request automatically closed after 5 days in the Review state.';
         changeGR.active = false;
         changeGR.update();
      }
}

All about Duplicate configuration Items in SNOW CMDB

The Problem with Duplicate CIs

Duplicate configuration items are a serious problem for any Configuration Management Database:

• Inaccurate inventory asset reports
• Could cost your company money on new licenses and maintenance
• Creates confusion when users are submitting ticket requests
• Makes it difficult to report on incident, change and problem trends
• Makes configuration management more difficult
• Can undermine the trust in configuration management

Getting rid of duplicate CIs is always a high priority for any configuration management team.

ServiceNow Discovery Preventing Duplicates

Each configuration item record is uniquely identified based on one or more field values specified in a CI Identifier Rule. A configuration item record is considered duplicate if the field values that uniquely identify it match the field values of another record of the same class.  By default, configuration items of class Hardware and all subclasses (Computer, Server, Unix Server, Windows Server) use the OS Serial Number as a unique identifier.  When SN Discovery or Service Mapping discovers a CI, the sensors and patterns use the internal function SNC.IdentificationEngineScriptableApi.createOrUpdateCI to send the CI to the CMDB.  If a CI already exists with the identifier attributes for that particular class, it is overwritten, otherwise a new CI is inserted. Here is sample JavaScript code invoking this function:

_________________________________________________________________________

var payload = {

            items: [{

              className: 'cmdb_ci_aix_server',

              values: {

                name: 'Aix Server 900',

                asset_tag: 'Asset 900',

                ip_address: '10.20.30.11',

                mac_address: 'ABCD1234',

                ram: '4096',

                cpu_name: 'SNow',

                serial_number: '123456783',

                cpu_type: 'SNow'

              }

            }]

};

var jsonUtil = new JSON();

var input = jsonUtil.encode(payload);

var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI ( 'ServiceNow', input);

1. gs.print ( output)

More details can be found here

Avoid duplicate incidents or stop processing inbound email actions further

Sometimes we observe that the system is creating multiple emails for an email received. This could be because multiple Inbound Email Actions have the same matching condition. All the inbound actions for which the condition is met will be executed and a record is created in that table.

We can avoid this by programmatically stopping the  ServiceNow system to stop processing the further inbound actions