- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sunday
Hi Community,
I have a requirement in ServiceNow CMDB where data is coming from the same server through two different sources:
Discovery
Import Set
Both sources are inserting records into the CMDB.
Business Requirement
Before inserting or updating a CI in CMDB, I need to compare the data from Discovery and the Import Set and check:
Whether both records belong to the same CI
Whether the attribute values are the same or different
Expected Behavior
If the data from both sources matches, allow the insert/update into CMDB.
If the data does not match, either:
Prevent the insert/update, or
Log the differences for review, or
Apply conditional logic based on priority (Discovery vs Import Set).
Questions
What is the best approach to compare data from Discovery and Import Set before CMDB insertion?
Should this be handled using:
Transform Map scripts?
Identification & Reconciliation Engine (IRE)?
Business Rules?
How can we efficiently compare records coming from different data sources before they update the same CI?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday
Hi @anburajselvaraj,
This is a very common CMDB scenario, and the key thing to understand is that you don’t need to manually compare Discovery and Import Set data before inserting into CMDB. ServiceNow already provides a built-in mechanism for this through the Identification & Reconciliation Engine (IRE).
Best practice - IRE
Use IRE Identification Rules to determine whether records coming from Discovery and the Import Set represent the same CI (based on CI Attributes such as FQDN, hostname, serial number, etc.).
This answers the question: “Is this the same CI or a new one?”
Reconciliation
Use IRE Reconciliation Rules to handle differences in attribute values.
Define source priority instead of comparing values manually.
What to use (and what not to use)
IRE ✅ (Primary solution)
Handles both: Same CI vs new CI, Which source updates which fields
Transform Maps ✅
Use them only to prepare data (normalize FQDN casing, trim values, map fields).Do not compare CMDB data here.
Business Rules ❌
Avoid using Business Rules on CMDB tables to compare or block updates. This causes performance issues and makes CMDB hard to maintain.
About your expected behaviors
If data matches → Update happens normally.
If data differs → Best approach: apply priority to source via reconciliation rules.
If needed, enable audit history for the cmdb tables and log the differences using audit history or reports.
Blocking updates is generally not recommended unless there is a strict business requirement.
Final takeaway
Let IRE do the comparison logically through identification and reconciliation.
Use Transform Maps only for normalization.
Avoid custom comparison logic in Business Rules.
If you find this helpful, please mark this response as Helpful and accept the solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday
Hi @anburajselvaraj,
This is a very common CMDB scenario, and the key thing to understand is that you don’t need to manually compare Discovery and Import Set data before inserting into CMDB. ServiceNow already provides a built-in mechanism for this through the Identification & Reconciliation Engine (IRE).
Best practice - IRE
Use IRE Identification Rules to determine whether records coming from Discovery and the Import Set represent the same CI (based on CI Attributes such as FQDN, hostname, serial number, etc.).
This answers the question: “Is this the same CI or a new one?”
Reconciliation
Use IRE Reconciliation Rules to handle differences in attribute values.
Define source priority instead of comparing values manually.
What to use (and what not to use)
IRE ✅ (Primary solution)
Handles both: Same CI vs new CI, Which source updates which fields
Transform Maps ✅
Use them only to prepare data (normalize FQDN casing, trim values, map fields).Do not compare CMDB data here.
Business Rules ❌
Avoid using Business Rules on CMDB tables to compare or block updates. This causes performance issues and makes CMDB hard to maintain.
About your expected behaviors
If data matches → Update happens normally.
If data differs → Best approach: apply priority to source via reconciliation rules.
If needed, enable audit history for the cmdb tables and log the differences using audit history or reports.
Blocking updates is generally not recommended unless there is a strict business requirement.
Final takeaway
Let IRE do the comparison logically through identification and reconciliation.
Use Transform Maps only for normalization.
Avoid custom comparison logic in Business Rules.
If you find this helpful, please mark this response as Helpful and accept the solution.
