Flip flopping serial number in Yokohama
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello, I am looking for assistance. Here are my Identification Rules, I am being told the Product Instance Identifier (which we are not using) should not be interfering with anything and it is fine being the OOB Rule and the highest priority. All my research is saying that it should be removed. Over the past few weeks I have had an increased in flip flopping serial numbers. An active CI that has been created manually through a MAC Flow is flip flopping with an already retired device in the CMDB. The only way I have found to resolve these flip flopping serial numbers is delete the both CI's and have them rediscover/recreate through SG-SCCM. I have been trying to track down the solution for this for 2 1/2 years and I just feel like I keep going in circles. Please note, we just upgraded to Yokohama in December and are priority used to be correlation ID first, which has sense been deprecated and correlation ID = serial number? Is that correct?
Priority Identifier Entry Attributes Used for Matching
| 90 | Product Instance Identifier | product_instance_id |
| 100 | Serial Number Table | serial_number, serial_number_type |
| 200 | Serial Number | serial_number (by itself) |
| 400 | Name and MAC Address | mac_address, name |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @nicolelmalo ,
This scenario occurs because the IRE rule checks the sys_object_source table before it evaluates the identifiers.
Initially, when a CI record is sent to the CMDB for the first time, it gets directly inserted because:
There is no existing entry in the sys_object_source table, and
There is no matching CI already present in the CMDB.
Later, when another record comes in with a different serial number for the same CI, the issue begins.
Before IRE evaluates the identifiers, it again checks the sys_object_source table. Since a matching source record is now found, the system performs a direct update based on the source mapping and skips identifier evaluation entirely.
As a result, the CI is treated as a new insert/update from the source, causing the serial number to keep changing (flapping) instead of being reconciled through identifiers.
I suggest deleting the existing records from the sys_object_source table and then re running the integration. If the issue still persists, verify whether the source_native_key values for the flapping serial numbers are unique. If they are not unique, you’ll need to ensure uniqueness by handling it appropriately in the ETL process.
Hope this helps you, Please do mark it as helpful . And accept the solution.
Thanks,
Vishnu

