Associating Incidents to a Problem

As defined by ITIL an ‘Incident’ is an unplanned disruption or reduction in quality of service and a ‘Problem’ is the underlying thing that caused the Incident. They are obviously related and there are endless pages on the internet going into incident and problem management as part of ITSM, so we won’t delve into this topic in any detail.

The key issue is resolving the incidents themselves isn’t always enough, you need to get to the route cause of the problem.

For example an Incident for “Database transaction log is full” could be fixed by clearing out the transaction log. But, if you’re getting many Incidents for the same thing, over a short period of time, there is clearly an underlying problem. In ITIL (and in ServiceNow), this means you will want to raise a Problem to find out the route cause and fix things, for example, in this case a fix might involve increasing transaction log size or finding out why there is more to log than before.

In ServiceNow you can manually associate a problem with an Incident but if you are looking to do this programmatically, the short function below allows you to quickly associate an Incident by its number to a Problem record by its number.

This is a server-side function and can be used in business rules to help track root cause analysis.

function associateProblemRecord(problemNumber, incidentNumber) {
    // We'll get the incident and problem records by their respective numbers
    
    // Create the glide record instance
    var prbGr = new GlideRecord('problem');
    var incGr = new GlideRecord('incident');

    // Using get will return the first match
    prbGr.get('number',problemNumber);
    incGr.get('number',incidentNumber);

    // Assign the problem to the incident and update it.
    incGr.problem_id = prbGr.sys_id;
    incGr.Update();
}

This function is available on our ServiceNow-Cookbook GitHub repository. We welcome you to fork the repository if you’d like to make you own updates. If you have additions that would be great for the whole community please submit a PR back to our repository and we’ll take a look.

Cookdown Ltd. takes no liability for the results of running these scripts. We recommend running them on a non-production instance before making any changes. We try our best to provide quality scripts in these posts, however, you should be familiar with the consequences of any action you are taking before executing these.

Previous
Previous

Update Rollup 10 for System Center 2016 has been released!

Next
Next

Why the difference between hosted & contained relationships matters with ServiceNow