Craig Jones1
Kilo Explorer

Hi all! So some of you will be in the same position I am currently in on my current implementation of ServiceNow. You have the basic ITSM functionality working as you want it, but discovery may still be ongoing, or you may still be trying to convience the powers that be to splash out on ITOM. 

If this is where you find yourself, then I have a little script that will help your fulfillers get to the cause of their incidents. In essence, it looks for change requests completed against the same CI that is on your incident record, and looks for changes that have been started in the last x number of days. If it finds one or more matches, it leaves these as a work note on the incident form, so the fulfillers will be able to check those change request records without having to dig around the change table trying to find out what has happened.

I have included the update set to this article for anyone that wants this on their system. It consists of a business rule and a system property. The system property contains the number of days you want to operate the search for, I separated this out to allow for easier editing for Admins.

If you just wanted to look at the code, here it is for you:

(function executeRule(current, previous /*null when async*/ ) {
    var gdt = new GlideDateTime();
    var days = gs.getProperty('change.causing.incident.days');
    gdt.addDays(-days);
    var allChanges = [];
    var gr = new GlideRecord('change_request');
    gr.addQuery('cmdb_ci', current.cmdb_ci);
	gr.addQuery('work_start', '>', gdt);
	gr.addQuery('work_start', '!=', '');
    gr.query();
    while (gr.next()) {
        allChanges.push(gr.number + '');
    }
    if (allChanges.length > 1) {
        current.work_notes = 'These change requests have been run in the last ' + days + ' days for the same configuration item: ' + allChanges + '. Please check to see if they caused this incident.';
    }
    if (allChanges.length == 1) {
        current.work_notes = 'This change request has been run in the last ' + days + ' days for the same configuration item: ' + allChanges + '. Please check to see if it caused this incident.';
    }
})(current, previous);

This has been created as a before business rule, on insert and update, with the conditions set as:

Configuration item changes 

and

Configuration item is not empty

It's pretty simple, but hopefully will save your fulfillers a little bit of time, and bridge the gap a little bit until your ITOM deployment. 

Version history
Last update:
‎03-06-2020 07:36 AM
Updated by: