If an integration is using api/now/identifyreconcile and which generally uses sys_object_source_info containing a source_native_key while sending in IRE payloads but wants to move this pointer to a new cmdb item rather than a previously deprecated or disposed cmdb item, how can the integration force the reconciliation rules to run again and map the previously used source_native_key to the newly matched cmdb item?
It depends on how the existing mapping record got deleted, in his question he said "previously deprecated or disposed cmdb item", when cmdb record gets deleted the mapping records in sys_object_source also get deleted through cascade delete. The clean up job is on the sys_object_source and it removes all the invalid target record mappings.
Yeah well general policy of most customers I have is that CMDB items are never truly deleted, just set to a "Status" that means they are not used/"Disposed" for reporting and other purposes. This is due to old CI records being a potentially historical record of note or indeed referenced by other records like Tasks/Incidents etc. In this case even clearing the name or serial or other IRE identifiers so the disposed CI does not match in any other way, the IRE will still keep offering this CI based on my source_native_key not having changed.
Given the cleanup rate of the sys_object_source is not predictable - plus I don't yet have an answer on how long the retention is typically, I would be left having to abandon using sys_object_source_info at all just due to this use case.
