Testing ServiceNow IRE with a Simple Script

ServiceNow’s Identification and Reconciliation Engine, usually shortened to IRE, is one of the most important parts of a healthy CMDB. It decides whether incoming CI data should create a new record, update an existing one, or be rejected based on identification rules, reconciliation rules, and data source priority.

When integrations start sending data into the CMDB, you do not want to find out in production that your identifiers are wrong, your source is not trusted, or your payload is creating duplicates.

That is why testing IRE directly is useful.

Why test IRE this way?

Using a small script lets you validate the behaviour of the IRE without needing to run a full integration, import set, discovery schedule, or external API call.

It helps you quickly answer questions like:

• Will this payload create a new CI?
• Will ServiceNow identify an existing CI correctly?
• Is my data source recognised?
• Are my identification rules working as expected?
• Is reconciliation allowing this source to update the fields I care about?

In short, it is a fast way to test the CMDB logic before blaming the integration.

The test script

You can run the following in Scripts - Background in a suitable sub-production instance:

var payload = {
    "items": [
        {
            "className": "cmdb_ci_win_server",
            "values": {
                "short_description": "DF Test",
                "name": "SerVer123456",
           
            }
        }
    ]
};
var input = new JSON().encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI('LANDesk', input);
gs.print(output);

What the script does

This script builds a simple IRE payload for a Windows Server CI using the cmdb_ci_win_server class.

The key fields are:

"className": "cmdb_ci_win_server"

This tells IRE what type of CI you are trying to create or update.

"name": "SerVer123456"

This is the CI value that IRE will try to use as part of the identification process, depending on your configured identification rules, you might want to use the Serial field instead.

'LANDesk'

This is the data source being passed into IRE. That matters because reconciliation rules may treat one source differently from another. It's also helpful if you want to test multieple source and CMDB360.

Finally, the script prints the IRE response:

gs.print(output);

That response tells you whether a CI was inserted, updated, matched, or whether there was an issue with the payload.

Why this matters

A clean CMDB depends on predictable identification. If IRE cannot confidently identify a CI, you risk duplicate records, poor relationships, broken service maps, and unreliable operational data.

This simple test gives you a quick feedback loop. Change the CI name, class, source, or attribute values, then rerun the script and review the result.

It is not a replacement for proper integration testing, but it is one of the fastest ways to prove whether your IRE rules are doing what you expect.

Final thought

Before sending thousands of records into the CMDB, send one.

Test it. Understand the IRE response. Fix the rules. Then scale with confidence.