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!

[Tanushree Maiti]

Hi @Pavan04 

Starting with the Australia release, IRE supports some non-CMDB tables. You can use all IRE features with some non-CMDB tables after creating identification rules (CI identifiers and identifier entries) for those tables. Non-CMDB tables supported for IRE features include:

• In an application-specific scope: All non-CMDB tables
• In the global scope: Only non-CMDB tables that are preset in the base system. In the Australia release for example, the Location [cmn_location], Department [cmn_department], Cost Center [cmn_cost_center], Building [cmn_building], User [sys_user], and Group [sys_user_group] non-CMDB tables are supported.

create and manage those rules as described in the following procedures:

• Create an identification rule for a non-CMDB table
• Create a reconciliation rule for a non-CMDB table
• Create an IRE data source rule for non-CMDB tables
• Create a data refresh rule for a non-CMDB table
• Create an identification inclusion rule for a non-CMDB table
• Simulate payload execution using identification simulation
• Use partial payloads
• Review and process de-duplication tasks

You can use the following store apps with supported non-CMDB tables:

• CMDB 360 in CMDB Workspace
• IntegrationHub ETL

IRE processes are applied to supported non-CMDB tables with the following differences:

• IRE doesn't populate the discovery_source, last_discovered, and the first_discovered attributes if those attributes don't exist in the non-CMDB table.
• IRE uses the non-CMDB table’s class name as sys_class_name if the table doesn't include a sys_class_name attribute.
• IRE payloads don't support relationships with non-CMDB tables.

Note:

Although IRE-related user interface and accompanying documentation might reference CMDB and CMDB elements, most of those references also apply to any supported non-CMDB tables.

Refer: IRE support for non-CMDB tables