We've updated the ServiceNow Community Code of Conduct, adding guidelines around AI usage, professionalism, and content violations. Read more

Flip flopping serial number in Yokohama

nicolelmalo
Tera Contributor

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

90Product Instance Identifierproduct_instance_id
100Serial Number Tableserial_numberserial_number_type
200Serial Numberserial_number (by itself)
400Name and MAC Addressmac_addressname

 

1 REPLY 1

Vishnu-K
Tera Guru

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.

VishnuK_0-1770700956061.png

 

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