Automatically Populating CI Fields in ServiceNow Incidents with SquaredUp Notifications

[Thanos]

With SquaredUp Cloud Notifications, it’s really convenient to send notifications to multiple destinations.

When ServiceNow is set as the destination for SquaredUp notifications, they appear as Self-Service Incidents, with the relevant information included in the Additional Comments section.

Here’s an example:

A customer requested an automatic way to populate the Configuration Item field in the Incident record. When SquaredUp sends the server name in the additional comments of the Incident. They wanted a solution to automatically map the CI field with the server name when a new incident is created.

I’ll outline how to parse fields in ServiceNow incidents using information from SquaredUp notifications.

Since the customer had already discovered Configuration Items in ServiceNow, the solution was to set up a Business Rule that would query the cmdb_ci table and populate the CI field with the correct server information based on the server name in the notification.

The CI field wasn’t initially present, so I added it using Form Designer before proceeding with the rest of the steps.

Note: To implement this solution, the user must have an admin role in ServiceNow.

Steps:

1. Create a new Business Rule on the Incident table in ServiceNow. The rule is set to trigger before the incident is saved, with the action set to insert which means the CI field gets updated right when the incident is created.

2. The filter conditions are set to match the filters used in your Incident table where Squaredup notifications are received.

3. In the Advanced section, I used the following script. It uses regex to extract the server name, then queries the cmdb_ci table to find the sys_id of the matching server. The fqdn column in the CMDB table contains the full server name in plain text, which made it easy to match and update the CI field on the incident with the corresponding sys_id.

(function executeRule(current, previous /*null when async*/) {
    // Extract the server name from the Additional Comments section
    var comments = current.comments;
    
    // Match using regex 
    var serverNameMatch = comments.match(/([a-zA-Z0-9-]+\.int\.domain\.com)/);
    
    if (serverNameMatch) {
        var serverName = serverNameMatch[0];  
        
        // Query the cmdb_ci table for the matching server name
        var ciGR = new GlideRecord('cmdb_ci');
        ciGR.addQuery('fqdn', serverName);
        ciGR.query();
        
        if (ciGR.next()) {
            // Update the CI field in the incident with the matching sys_id of CI
            current.cmdb_ci = ciGR.sys_id;
        } else {
            gs.info("CI for server " + serverName + " not found.");
        }
    } else {
        gs.info("No matching server name found in Additional comments.");
    }
})(current, previous);

Once you receive a new incident, the CI will be automatically updated.

[pchip (Pascal Verdieu)]

Hey Thanos,

I don’t use SQ Cloud, so don’t know if you could modify the notification to send the affected item separately. Then it would be easier to get said CI from it instead of using Regex, as you’re now stuck to only servers. Say you have a new alert at application level (outside in), you will not be able to search for that CI.

That said, cmdb_ci contains all CIs, and as is your query, you will have no way to distinguish the cmdb_ci_win_server CI from the cmdb_ci_vmware_instance CI with the same FQDN. I would recommend using cmdb_ci_server as base, if you’re forced to only look at servers.

You are inevitable

[Thanos]

Hey Pascal,

Currently, we don’t directly map the affected item to a CI, as ServiceNow provides the flexibility to handle that mapping. That said, I completely agree with your second recommendation - using cmdb_ci_server as the base makes a lot of sense if we’re focusing only on servers.

Thanks for your thoughts - super helpful!