A physical server may appear in a discovery tool, endpoint platform, asset register and infrastructure inventory. Those systems may legitimately agree about identity while differing on operating-system version, location, owner or last seen. Creating one CI per source produces duplicates; allowing every integration to overwrite any field produces a \u201clast writer wins\u201d CMDB. CMDB 360\/multisource capabilities address the need to inspect source contributions, while the Identification and Reconciliation Engine enforces identity and attribute authority.<\/p>\n
ServiceNow describes the distinction in its IRE<\/a> reference. Identification resolves an incoming CI against existing objects. Reconciliation rules determine which source is allowed to modify defined attributes, often at particular class or priority scopes. CMDB 360 makes source-specific evidence more useful to investigate; it should not be portrayed as proof that the newest value is the most accurate.<\/p>\n For an illustrative host, Discovery reports a running Linux version, the asset system stores the cost center, and the application team maintains service ownership. A conflict over cost center should not be resolved by changing a network probe. The first question is which business process owns that attribute and whether its source has been properly authorized.<\/p>\n Start with a source payload containing a class, identifiers and several attributes. IRE attempts to find the existing CI using configured identification rules, or class-appropriate source identifiers where supported. The result may be a match, a new record or an error that requires investigation. Successful matching does not imply every field in the payload will be accepted; reconciliation and source rules still control eligible writes.<\/p>\n CMDB identification and reconciliation<\/a> depend on stable identifiers and clear source authority. A useful advanced test sends two payloads for one server with the same stable identity but different owner values. Record which source was authorized for that attribute, the effective value after each arrival, and whether a blocked overwrite was intentional. An intentionally rejected update is not the same as an ingestion failure.<\/p>\n Source provenance should remain interpretable. If an integration labels one source \u201cInventory\u201d today and \u201cDeviceDB\u201d tomorrow, a policy depending on a stable source name may behave differently. Include source labels, identifiers and processing outcomes in change control; do not infer from a record timestamp alone which system owns the current attribute.<\/p>\n ServiceNow reconciliation rules<\/a> include static and dynamic forms, with documented precedence behavior when both apply to a field. Their purpose is to prevent unauthorized sources from overwriting data even if they submit a syntactically valid payload. A single integration can be authoritative for technical state yet not for business ownership, which argues for attribute-level rather than indiscriminate source-level control.<\/p>\n An operating-system version field should normally follow a trusted current technical feed. A system-of-record asset identifier may come from asset management. A critical service owner may require manual approval. Before defining priority, specify semantic responsibility, expected freshness, acceptable fallback and how stale primary data is escalated. Never \u201cfix\u201d a source authority conflict by giving every source the highest priority.<\/p>\n During planned source migration, introduce the successor feed in a controlled stage. Compare both sources for sample CIs, identify disagreements and inspect authorization decisions. The switch must preserve CI identity and attached incidents, relationships and asset references. A migration can appear successful by inserting new records but still leave the CMDB fragmented.<\/p>\n A multisource view is useful because it lets an operator inspect more than one submitted interpretation of a CI. It helps investigate why the normalized record has a specific value and whether lower-priority evidence suggests a source problem. It does not automatically judge which conflicting value is true under every business circumstance. The organization still needs accountable owners and a rule for authoritative data.<\/p>\n Consider a host marked retired in an asset system but still discovered each day. One possibility is an incorrect retirement; another is a reused hostname; a third is the discovery feed representing a replacement machine. Inspect source-native identifiers, asset lifecycle evidence and class identity before overwriting either record. A dashboard that displays both sources can highlight the conflict but cannot determine the correct business decision unaided.<\/p>\nTrace the data path from source to effective CI<\/h2>\n
Use static and dynamic reconciliation deliberately<\/h2>\n
Distinguish CMDB 360 visibility from governance<\/h2>\n