Data flapping issues while using the SCCM importsIssue Data flapping issues while using the SCCM importsReleaseAllResolutionGeneral Behavior : While uploading data into cmdb tables using the SCCM imports, Initial check happens on the data availability in the sys_object_source tablehttps://<instance_name>.service-now.com/sys_object_source_list.do?Based on the data available in the sys_object_source table, with whatever information that comes from the SCCM payload, as per the OOB set up, the check validation happens based on the correlation id, as per the below transform scripthttps://<instance_name>.service-now.com/sys_transform_entry.do?sys_id=21d9c11f5b223200dade2e65f0f91ad4&sysparm_view=&sysparm_record_target=sys_transform_entry&sysparm_record_row=1&sysparm_record_list=map%3Dedf48d9b5b223200dade2e65f0f91abe&sysparm_record_rows=9if (DiscoveryCMDBUtil.useCMDBIdentifiers()) {// First attempt to shortcut identification by looking at sys_object_sourcevar matches = IDByObjectSource();// If one match, we have successfully identified the CI through sys_object_sourceif (matches.length == 1) {var matchSysId = matches[0];logUpdate(matchSysId, "sys_object_source");return matchSysId;}The above lines of code are calling a function "IDByObjectSource". This function updates the values based on the correlation id.Please refer to the below lines of code from the same scriptfunction IDByObjectSource() {var matches = [];var gr = new GlideRecord("sys_object_source");gr.addQuery("name", "SCCM");gr.addQuery("id", ciData.getData().correlation_id);gr.addNotNullQuery("target_sys_id");gr.addQuery("target_table", ciData.getData().sys_class_name);gr.query();while (gr.next()) {// Verify it actually exists...var grr = new GlideRecord(ciData.getData().sys_class_name);if (grr.get(gr.target_sys_id))matches.push(gr.target_sys_id + '');If there exists a single unique record in the sys_object_source table with the same correlation id obtained from the payload, then the matching happens at the correlation id and all the other associated attributes are updated accordingly.If there exists no records or multiple records in the sys_object_source table with the same correlation id from the payload, then the matching does not honor the above transform script and follows the normal identification procedure based on the IRE rules set up on that particular class in the Class Manager. Issue Scenarios : Scenario 1 : Correlation id being same but the name and other attributes on the CI getting flapped This is because of the possibility that there may have been a record in the sys_object_source table with the same correlation id from the payload but with the new name, serial number etc, thus keeping the correlation id as is, the other associated attributes gets updated against the CI in the CMDB tables. Scenario 2 : Correlation id flapping on a CI This is because of the possibility that there are no records or multiple records in the sys_object_source table with the correlation id obtained on the payload. Here it will not honor the transform script and goes with the traditional identification rules (IRE) as per the set identifiers on the that particular class in the class manager. By default, for any particular class, correlation id holds the highest priority, followed by serial number and serial number type, followed by name etc as part of the default identifiers set.So, the search happens for any existing records in the cmdb tables with the correlation id from payload, if none found, then it moves to the serial number and serial number type and if no match found, then looks at the next attribute that is name. In this particular scenario, the match at the IRE level should have happened at the serial number or the name attributes.