Duplicate CI-Asset Creation and Asset-CI Linking Issue

[ArafathA]

Hi All,
We have an existing CI in the CMDB discovered through SG-Intune. As the OOB CI-Asset linking Business Rule was previously disabled, no asset record was created or associated with this CI.
After enabling the Business Rule in Production, we created a new asset expecting it to link to the existing discovered CI. However, ServiceNow created a new CI with the same serial number instead of linking the asset to the existing CI, resulting in a duplicate CI record.
Could you please help and advice on the recommended approach to:
Remediate the duplicate CI records in the CMDB.
Link the asset to the existing discovered CI.
Prevent similar duplicate CI creation in the future.

[vaishali231 · Accepted solution]

Hey @ArafathA 

This behavior is generally expected when the OOB CI-Asset Linking Business Rule has been disabled for a period of time. Once the rule is re-enabled, it does not automatically reconcile or relink historical records that were created while it was disabled.

The Business Rule itself is not responsible for duplicate detection or CI reconciliation. It only establishes the relationship between an Asset and a CI when the platform can successfully identify an existing CI.

Recommended Remediation

Step 1: Identify the Authoritative CI

Determine which CI should remain in the CMDB.

In most environments, the discovered CI should be retained because it typically contains:

Discovery source information

Relationships (cmdb_rel_ci)

Installed software

Network attributes

Discovery history

Reconciliation metadata

The manually created duplicate CI usually contains minimal information and is generally the better candidate for retirement or deletion after validation.

Before removing any CI, verify:

Incident references

Change Requests

Problem records

Request Items

Service mappings

CI Relationships

Software installations

Any custom application references

If both CIs contain valuable information, consider merging the data first rather than immediately deleting one of the records.

Step 2: Link the Asset to the Existing CI

Once the duplicate CI has been removed (or identified for retirement):

1. Open the Asset record.
2. Populate the Configuration Item (CI) reference with the existing discovered CI.
3. Verify the corresponding Asset reference on the CI.
4. Confirm that both records reference each other correctly.

If you have many records to fix, a background script or Fix Script can safely update both references in bulk.

Step 3: Investigate Why the Existing CI Was Not Identified

This is the most important step because it determines why a duplicate was created.

Review Identification Rules

Check the Identification Rule configured for the affected CI class.

Verify:

Is Serial Number included?

Is it the primary identifier?

Are additional identifiers required (Name, UUID, Object ID, etc.)?

Is the rule active?

If the incoming Asset data does not satisfy the Identification Rule, ServiceNow will create a new CI instead of updating the existing one.

Validate Through the Identification Simulator

Run the Identification Simulator using the values received from:

SG-Intune Discovery

Asset Creation

The simulator will show:

Which Identification Rule was evaluated

Which identifiers matched

Why the existing CI was not selected

Why a new CI was created

This is often the fastest way to identify the root cause.

Review IRE (Identification and Reconciliation Engine)

If your environment uses Discovery, Service Graph Connectors, or IntegrationHub ETL, ensure all integrations are using the Identification and Reconciliation Engine (IRE).

Creating CIs through direct GlideRecord inserts or imports that bypass IRE can result in duplicate records because identification logic is skipped.

Verify Serial Number Consistency

Serial number mismatches are one of the most common causes of duplicate CIs.

Check for differences such as:

Uppercase vs lowercase

Leading/trailing spaces

Different formatting

Missing serial numbers

Manufacturer-specific formatting

Even small inconsistencies can prevent successful identification.

Review the Asset Creation Process

Understand how the Asset was created.

Examples include:

Manual Asset creation

Procurement

Import Set

Integration

Asset Management process

If the process inserts a new CI without first identifying an existing one, duplicates may occur.

Preventing Future Duplicates

I would recommend the following best practices:

Keep the OOB CI-Asset Linking Business Rule enabled.

Ensure all CI creation processes use the Identification and Reconciliation Engine (IRE).

Validate Identification Rules for every managed CI class.

Standardize serial number formatting across discovery and asset sources.

Periodically review CMDB duplicate reports.

Enable CMDB Duplicate Management or CMDB Data Manager (where available) to identify and remediate duplicates proactively.

Test any new integrations using the Identification Simulator before deploying them to Production.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[vaishali231 · Accepted solution]

Hey @ArafathA 

This behavior is generally expected when the OOB CI-Asset Linking Business Rule has been disabled for a period of time. Once the rule is re-enabled, it does not automatically reconcile or relink historical records that were created while it was disabled.

The Business Rule itself is not responsible for duplicate detection or CI reconciliation. It only establishes the relationship between an Asset and a CI when the platform can successfully identify an existing CI.

Recommended Remediation

Step 1: Identify the Authoritative CI

Determine which CI should remain in the CMDB.

In most environments, the discovered CI should be retained because it typically contains:

Discovery source information

Relationships (cmdb_rel_ci)

Installed software

Network attributes

Discovery history

Reconciliation metadata

The manually created duplicate CI usually contains minimal information and is generally the better candidate for retirement or deletion after validation.

Before removing any CI, verify:

Incident references

Change Requests

Problem records

Request Items

Service mappings

CI Relationships

Software installations

Any custom application references

If both CIs contain valuable information, consider merging the data first rather than immediately deleting one of the records.

Step 2: Link the Asset to the Existing CI

Once the duplicate CI has been removed (or identified for retirement):

1. Open the Asset record.
2. Populate the Configuration Item (CI) reference with the existing discovered CI.
3. Verify the corresponding Asset reference on the CI.
4. Confirm that both records reference each other correctly.

If you have many records to fix, a background script or Fix Script can safely update both references in bulk.

Step 3: Investigate Why the Existing CI Was Not Identified

This is the most important step because it determines why a duplicate was created.

Review Identification Rules

Check the Identification Rule configured for the affected CI class.

Verify:

Is Serial Number included?

Is it the primary identifier?

Are additional identifiers required (Name, UUID, Object ID, etc.)?

Is the rule active?

If the incoming Asset data does not satisfy the Identification Rule, ServiceNow will create a new CI instead of updating the existing one.

Validate Through the Identification Simulator

Run the Identification Simulator using the values received from:

SG-Intune Discovery

Asset Creation

The simulator will show:

Which Identification Rule was evaluated

Which identifiers matched

Why the existing CI was not selected

Why a new CI was created

This is often the fastest way to identify the root cause.

Review IRE (Identification and Reconciliation Engine)

If your environment uses Discovery, Service Graph Connectors, or IntegrationHub ETL, ensure all integrations are using the Identification and Reconciliation Engine (IRE).

Creating CIs through direct GlideRecord inserts or imports that bypass IRE can result in duplicate records because identification logic is skipped.

Verify Serial Number Consistency

Serial number mismatches are one of the most common causes of duplicate CIs.

Check for differences such as:

Uppercase vs lowercase

Leading/trailing spaces

Different formatting

Missing serial numbers

Manufacturer-specific formatting

Even small inconsistencies can prevent successful identification.

Review the Asset Creation Process

Understand how the Asset was created.

Examples include:

Manual Asset creation

Procurement

Import Set

Integration

Asset Management process

If the process inserts a new CI without first identifying an existing one, duplicates may occur.

Preventing Future Duplicates

I would recommend the following best practices:

Keep the OOB CI-Asset Linking Business Rule enabled.

Ensure all CI creation processes use the Identification and Reconciliation Engine (IRE).

Validate Identification Rules for every managed CI class.

Standardize serial number formatting across discovery and asset sources.

Periodically review CMDB duplicate reports.

Enable CMDB Duplicate Management or CMDB Data Manager (where available) to identify and remediate duplicates proactively.

Test any new integrations using the Identification Simulator before deploying them to Production.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[ArafathA]

Hi @vaishali231 ,

We are observing an issue where creating a hardware asset manually results in a duplicate CI being created, even though a CI with the same serial number already exists.

To validate the identification rule, we ran an IRE Simulation for the cmdb_ci_computer class using the existing CI's serial number as the criterion attribute and SNAssetManagement as the discovery source. The simulation successfully identified the existing CI, showing "Matching serial number found" with the result "UPDATE", confirming that the identification rule is functioning as expected.

However, when a hardware asset is created manually using the same serial number, instead of updating or linking to the existing CI, the platform creates a new CI, resulting in a duplicate record.

Since the IRE simulation behaves as expected, we would like to understand why the manual asset creation process is not identifying and updating the existing CI, and instead creates a duplicate CI.

[Pratiksha · Accepted solution]

Hi @ArafathA ,

Manual creation wont be stopped. Only if you are trying to discover it or insert with the help of SGC( API) then only the it will use IRE. 

Two things to do : 

1) if you are using Intune dont create CI manually.

2) If you using app to scan the assets make sure you add model and model category. 

Hope it helps. 

Regards, 

Pratiksha