CMDB CI Missing Due to Multiple Serial Number and Source Records Updating the Same CI

[Kent Gloriana]

Hi Everyone,

I'm currently investigating an issue in our ServiceNow CMDB where some expected CIs are missing.

After reviewing the data, I found that multiple entries in the CMDB Serial Number table (cmdb_serial_number) and multiple records in the Source table (sys_object_source) appear to be associated with and updating the same CI. As a result, different devices that should exist as separate CIs seem to be getting consolidated into a single CI record.

For example:

• Device A and Device B exist as separate devices in the source system.
• Each device has its own hostname, serial number, and source record.
• However, in CMDB, both source records end up updating the same CI.
• The other expected CI is never created, which results in a missing CI in the CMDB.

I would like to understand the following:

1. What are the best practices for investigating and correcting this issue?
2. How should incorrect records in cmdb_serial_number and sys_object_source be handled?
3. Is it recommended to delete incorrect serial number relationships and source mappings so that the next import/discovery can create the missing CI correctly?
4. What are the common causes of multiple source records updating a single CI?
5. Are there any recommended approaches to prevent this from recurring, particularly when using SCCM/Import Sets/IRE?

[abbasshaik4]

Hello @Kent Gloriana,

Please refer to the link's below:
Serial Number changing on CI records, causing dupl... - ServiceNow Community

How to troubleshoot duplicate CMDB CI records - Support and Troubleshooting

If it is helpful, please mark it as helpful and accept the correct solution by referring to this solution in the future it will be helpful to them.

Thanks & Regards,

Abbas Shaik

[Vishnu-K]

Hi @Kent Gloriana ,

When it comes to sys_object_source, its main purpose is to reduce the processing burden on IRE and make identification faster. When a CI is created through IRE, a corresponding sys_object_source record is created with the Source Native Key, which is usually the source system's unique ID.

During the next import, ServiceNow first checks this Source Native Key. If it matches an existing sys_object_source record, it directly identifies the CI and updates it based on the reconciliation rules. If there is no match, the payload goes through the normal IRE identification rules for that class.

In this case, if incorrect sys_object_source mappings are causing multiple source records to point to the same CI, you can remove the incorrect mappings so the next import can go through IRE again and potentially create the missing CI. However, this should only be done after confirming that the Source Native Key is unique for each device. Otherwise, the same issue can occur again.

This approach is particularly relevant when using Service Graph Connectors (SGCs), where sys_object_source plays an important role in source-to-CMDB identification.

Hope this helps, if it helped you please do mark it as helpful and accept the solution

Thanks,

Vishnu

[Kent Gloriana]

Hi Vishnu,

Thank you for the explanation.

Based on your response, am I correct in understanding that when multiple sys_object_source records are incorrectly mapped to the same CI, the resolution is to identify and remove the incorrect sys_object_source mappings so that the next import can go through IRE and create the missing CI correctly?

If that's the case, what would be the recommended approach when dealing with a large number of affected records, such as 50 to 100 CIs? Is this typically a manual investigation and cleanup process, or are there any best practices, reports, or automated methods that can help identify and remediate incorrect sys_object_source mappings at scale?

Thank you.