Can Identification and Reconciliation Engine (IRE) be fully implemented for a non-CMDB table (cmn_lo

[Pavan04]

Hi Team,

I'm working on implementing Identification and Reconciliation Engine (IRE) for the cmn_location table to prevent duplicate Location records across multiple data sources.

Current Scenario

We have Location data being created and updated from multiple sources, including:

• Import Set + Transform Maps

• HR integrations

• Workday

• SGC

• Other third-party integrations

• Manual record creation

• Direct GlideRecord/API inserts

Our goal is to ensure every insert and update to the cmn_location table goes through the Identification Engine so duplicate Locations are prevented consistently.

What we've done

• Configured the cmn_location table to support IRE (non-CMDB table support).

• Created Identification Rules (cmdb_identifier) for the Location table.

Challenge

From our testing, it appears that simply configuring IRE does not automatically cause every data source to invoke the Identification Engine.

For example:

• Import Sets can potentially call the Identification Engine using Util.

• However, HR integrations, REST integrations, direct GlideRecord inserts, Business Rules, and manual record creation do not appear to automatically invoke IRE.

This makes it difficult to guarantee duplicate prevention across all ingestion paths.

Questions:

1. Is it officially supported to implement IRE as the primary duplicate prevention mechanism for a non-CMDB table like cmn_location?

2. Can every insert/update to a non-CMDB table be forced through the Identification Engine?

3. Is there an out-of-the-box mechanism that automatically routes all data sources through IRE?

4. If not, is the recommended approach to explicitly invoke the Identification Engine from every integration and Transform Map?

5. Has anyone successfully implemented IRE for cmn_location or another non-CMDB table across multiple data sources?

Any guidance, best practices, or implementation experience would be greatly appreciated.

Thank you!

[Dr Atul G- LNG]

Hi @Pavan04 

yes ,https://www.servicenow.com/docs/r/servicenow-platform/configuration-management-database-cmdb/ire-sup...

Yes, the Identification and Reconciliation Engine (IRE) can be fully implemented for non-CMDB tables in ServiceNow, allowing you to establish unique identification, attribute-level precedence, and data integrity for non-CI data. [1, 2]

Implementation Details

• Scope Rules: Custom non-CMDB tables in an application-specific scope are fully supported. Global scope non-CMDB implementations are restricted to preset base system tables (like sys_user or cmn_location). [1]

• Configuration Location: You cannot use the CI Class Manager for non-CMDB tables; you must configure entries under CI Identifiers directly in the IRE application. [1]

• System Properties: Ensure the system property glide.identification_engine.non_cmdb_tables is enabled. [1]

Supported Features

• Identification Rules: Define unique criteria using table attributes and parent-child references.

• Reconciliation Rules: Set data source precedence to control which integration updates specific fields.

• Data Refresh & Source Rules: Manage update intervals and restrict specific data sources from inserting new records

[Pavan04]

Hi @Dr Atul G- LNG ,

Thanks for your response and for looking into this.

I had already gone through the documentation you shared, and it does explain how to configure IRE for non-CMDB tables.

However, my requirement is.

In our environment, Location data is being created from multiple sources such as HR, Workday, integrations, Import Sets, APIs, and even manual entries. At the moment, these feeds are writing directly to the cmn_location table without going through the Identification Engine, which is leading to duplicate records with the same Name, Site ID, and other key attributes.

What I’m trying to achieve is not just enabling IRE on the table, but ensuring that every insert or update—regardless of source—is validated through IRE before the record is created or updated.

Could you please confirm if there is any out-of-the-box way to enforce this for all data ingestion paths on a non-CMDB table? Or is it required that each integration, import, or API explicitly call the Identification Engine?

Thanks again, @Dr Atul G- LNG .

[Dr Atul G- LNG]

SOrry @Pavan04 

I'm not 100% sure about this. Technically, it should work as per the documentation. If you've followed the documented steps and it's still not working, it's better to log a ServiceNow Support case so the team can investigate the issue further.

[Nishant8]

Hello @Pavan04 , By default, ServiceNow only routes data through the IRE if the incoming channel specifically calls the IRE API. Since your data comes from multiple sources, you should plan to align them with the appropriate ingestion methods such as:
Workday and HR: Use IntegrationHub ETL to feed and process this data.
Standard Import Sets & Transform Maps: Because these do not use the IRE by default, you must add an onBefore script to the Transform Map using the CMDBTransformUtil API.
Direct GlideRecord Inserts or Custom APIs: Format incoming payloads to utilize the IdentificationEngineScriptableApi.
Manual Entries: Avoid manual creation where possible. If it is absolutely required, implement a before-insert Business Rule on the Location table that uses the IdentificationEngineScriptableApi to catch duplicates.

Regards,

Nishant