Hello community,
During my preparation for the CIS – Data Foundations, I came across this little helper tool that I hadn’t heard of before. While many of you ITOM experts may already use it regularly, I don’t; and that’s exactly why I want to share my experience and ideas as part of this article.
Introduction
The Identification and Reconciliation Engine (IRE) is central to how ServiceNow maintains accurate, de‑duplicated CIs in the CMDB. Before you push real discovery or import‑set data into production, you can use Identification Simulation to generate and test payloads, and then reuse those same payloads to import mock or sample data into your platform.
This article is aimed at people working in the CMDB area or solution advisory space who want to:
- validate identification rules safely,
- understand how payloads are structured, and
- reuse generated payloads to populate or test CMDB data without relying on live discovery.
What Identification Simulation Does
Identification Simulation is a central UI for automatically constructing an input payload that is guaranteed to be complete and valid for the IRE. You can:
- automatically generate a payload for a given CI class,
- simulate how the IRE would process it, and
- inspect the logs and output without committing any changes to the CMDB.
The generated payload includes all required dependent CIs, correctly structured and syntactically valid, based on your existing identification rules, hosting, and containment rules.
Generating a Payload: Linux Server Example
To illustrate how Identification Simulation works, let’s walk through a concrete example using a Linux server (`cmdb_ci_linux_server`). The same pattern applies to any CI class you choose.
1. Navigate to Configuration > Identification/Reconciliation > Identification Simulation.
2. In Start with CI Class, select Linux Server (`cmdb_ci_linux_server`).
3. In Criterion Attributes, specify the attributes that uniquely identify the Linux server, such as `name` or `serial_number`, depending on your identification rule.
4. In Additional Attributes, add fields you want to update on the server, for example `ip_address`, `os`, or `manufacturer`.
5. For dependent CIs (for example, an operating system or network adapter), fill out the Criterion and Additional Attributes in each Container‑level section that appears.
6. Click Generate Script; if fields are missing, the UI will prompt you to complete them.
After generating the script, you can click Run Simulation to see how the IRE would process the payload, including logs and the output payload, without touching the CMDB.
Using the Generated Payload to Import Mock Data
Once you have a valid payload (for example, for `cmdb_ci_linux_server`), you can reuse it to import mock or sample data into the CMDB instead of relying only on discovery or real‑world imports.
Option 1: Direct IRE API call
You can call the `createOrUpdateCI()` API with the generated payload to execute it through the IRE and actually update the CMDB. This is useful when:
- you want to simulate a discovery‑style data source,
- you need to populate a non‑production environment with realistic CI structures, or
- you are testing data‑source precedence and reconciliation behavior.
In a script include, business rule, or background script, you can paste the JSON and invoke the API, adjusting values as needed for your test scenario.
Option 2: Import Sets with CMDBTransformUtil
If you prefer to work with Import Sets, you can use the CMDBTransformUtil API in the `onBefore` transform map script to apply identification and reconciliation to imported rows. The API internally passes data to the IRE, so you can:
- design a CSV or import‑set structure that mirrors the generated payload’s attributes,
- use the payload as a reference for which fields and relationships matter, and
- ensure duplicates are handled according to your identification rules.
Practical Use Cases
Here are concrete scenarios where this approach helps:
Testing identification rules in isolation
Use Identification Simulation to generate a payload, run the simulation, and adjust rules until the output matches your expectations; without risking live data.
Populating test or demo environments
Generate payloads for key CI classes, then import them via the IRE or Import Sets to build a realistic CMDB structure for demos, training, or performance tests.
Validating data‑source precedence and reconciliation
Import mock payloads from different “data sources” and verify that the IRE correctly reconciles attributes according to your CMDB data‑source rules.
Onboarding new consultants or teams
Provide a small set of generated payloads as reference examples so new team members can see how identification rules translate into actual CI structures.
Best Practices and Pitfalls
- Always start in a non‑production environment and keep the simulation step active until you are confident in the payload structure.
- Keep identification rules simple and limit the number of identifier entries per rule to maintain performance.
- When reusing payloads for imports, review data‑source precedence so that mock data does not accidentally overwrite authoritative sources in production.
Share Your Experience and Feedback
If you’ve used Identification Simulation in your own environments, I’d love to hear how.
Please share your tips, edge cases, or additional examples in the comments; especially if you’ve used it to test other CI classes or integrate it with custom data sources.
If you found this article helpful, feel free to like it and share it with colleagues who work with the CMDB or IRE.
