IRE Identification and Reconciliation Guide

Identification rulesReconciliation controlsSource precedence

HOW THE SOLUTION FLOWS

Multi-source CI ingestion through IRE

Every source declares its identity. IRE first matches the CI, then checks whether that source may update each attribute.

01External Source A

02IRE-aware pipeline

03Identification

04Reconciliation

05One trusted CI

Identification answers: Is this CI already present?

Identification rules compare incoming data with existing CIs using reliable identifiers. If a match is found, IRE updates the existing CI. If no match is found, it can create a new CI.

Use stable identifiers
Define ordered identifier entries
Avoid relying only on display names

Reconciliation answers: Can this source update the attribute?

Reconciliation rules protect trusted values. A lower-priority source may identify the correct CI but can still be prevented from overwriting attributes owned by a more trusted source.

Recommended multi-source design

Give every external source its own discovery source and ingestion pipeline. Load through an IRE-aware mechanism and define ownership per attribute instead of choosing one source for the entire CI.

Separate discovery sources
IRE-aware ingestion
Attribute-level precedence
Test inserts, updates and rejected updates

Implementation steps

Follow these steps in a personal developer or sub-production instance. Validate backend names and choice values before using the solution in production.

Define source contracts

WHERE: Architecture design

Document classes, identifiers, required attributes, update frequency and the owner for each external source.

Create separate discovery sources

WHERE: CMDB data source design

Do not label two integrations with the same generic source. Reconciliation depends on source identity.

Review identification rules

WHERE: CI Class Manager

Use stable identifiers in an intentional order. Test payloads with and without the primary identifier.

Configure attribute ownership

WHERE: Reconciliation definitions

Assign hardware attributes to the trusted hardware source and operational attributes to the operational source.

Load through IRE

WHERE: Integration implementation

Use IntegrationHub ETL, an IRE-enabled import path or the supported IRE API. Never insert directly into a CI table.

Test both source orders

WHERE: Sub-production test

Create with A then update with B, repeat in reverse order and verify rejected attributes.

Send a server CI payload through IRE

Use a discovery source name that exactly matches the governed source. Confirm the API and payload contract supported by your release before production use.

javascript

var payload = {
    items: [{
        className: 'cmdb_ci_server',
        values: {
            name: 'APP-SRV-101',
            serial_number: 'SN-100101',
            environment: 'Production'
        }
    }]
};

var result = SNC.IdentificationEngineScriptableApi
    .createOrUpdateCI('External Source A', JSON.stringify(payload));

gs.info(result);

How to test it

1New payload creates one CI
2Same identifier updates the existing CI
3Source B cannot overwrite Source A hardware fields
4Source B can update its owned operational fields
5Missing identifier creates a controlled reject or expected result
6Duplicate remediation does not hide the source defect

Common mistakes

Direct GlideRecord insert into cmdb_ci
Using name as the only identifier
One discovery source for every integration
CI-level precedence instead of attribute ownership
Deleting duplicates before fixing ingestion

INTERVIEW PRACTICE

Can you explain this solution under pressure?

Practice real scenarios covering this topic, architecture decisions, troubleshooting and security.

Open 64+ scenarios →

Continue learning with Ravi.

Explore more implementation guides or request the next topic.

All documents Request a topic →