I’m using the Armis Service Graph Connector on Yokohama Patch 7, and running into a serious CMDB issue related to unstable Armis IDs.
Armis sends its internal device ID into sys_object_source.source_native_key.
However, in my environment, the same Armis ID is later reused for a completely different device (different serial, MAC, etc.).
When this happens:
IRE finds the old sys_object_source entry for that Armis ID
IRE updates the previous CI instead of creating a new one
This causes CI hijacking, where Device A gets overwritten with Device B’s data
Example:
Armis ID 121 → Device A today
Later Armis ID 121 → Device B
IRE updates Device A with Device B’s attributes
My identification rules (serial + MAC) are correct, but IRE still follows the existing sys_object_source link.
My questions to the community:
Is unstable/recycled Armis IDs a known issue on the Armis side?
Has anyone else seen this behavior?
Is there a ServiceNow-side configuration (IRE behavior/prevention rules) that can stop IRE from updating a CI when the Armis ID’s identity changes?
- Can we stop using the sys_object_source data for Identification and let the system use the Identifiers defined at class level?
Or should this only be fixed on the Armis side by ensuring stable IDs?
Any guidance or best practices would be really appreciated.
