Two systems can describe the same server accurately and disagree about its state. A cloud inventory service may report a resource as running while an endpoint-management platform says its agent has not checked in for two days. If an administrator simply chooses the latest row in a spreadsheet, the resulting CMDB can become a contest between integrations. ServiceNow CMDB 360 and multisource capabilities make that disagreement visible so teams can decide which source should control each attribute and which observation requires investigation.
CMDB 360 is valuable when it makes a disputed attribute explainable. Suppose Discovery reports a server’s old location, a virtual-infrastructure connector reports the new location and the endpoint inventory has no recent observation. The design must first identify the single CI correctly, then apply class-specific reconciliation authority to its current attributes while retaining source evidence and timestamps. An incorrect identification rule can create two records before multisource reconciliation begins; a correct identity with stale source priority can still produce the wrong current value. An answer to independent CIS-DF multisource practice questions must first establish that both sources describe the same CI, then name the source authorized to update its disputed attribute and choose the CMDB 360 query that can verify the mismatch. This is a design exercise, not an executed ServiceNow test.
Start by deciding what each source actually knows
Discovery may have strong evidence about technical attributes observed through a supported probe, while an asset register can be better for purchasing and ownership details. A cloud platform can report provider-native instance IDs and regions, but it may not know the team accountable for an application. Source credibility is therefore specific to a field and an operational purpose. Calling one integration globally authoritative for everything can overwrite correct information with values that source never meant to govern.
Create a field-by-source matrix for the hospital. Its rows include CI class, stable identifier, operating system, environment, physical location, support group and lifecycle stage. Its columns are the participating systems. Mark which source can provide direct observation, which carries delegated business authority and which is permitted only to supplement missing data. Include freshness requirements and how the owner will recognize when a source has stopped reporting. This matrix should exist before anyone sets reconciliation priority.
Separate identification from multisource evidence
ServiceNow’s Identification and Reconciliation Engine provides rules to match incoming configuration data to existing CIs and govern updates. Identification asks whether an incoming object is already known; reconciliation asks whether its source may alter a particular property. CMDB 360 adds a view of the information reported by distinct sources so differences can be examined instead of flattened into whichever value happened to write last.
A cloud VM’s provider instance identifier can remain stable when its display name changes, while unrelated VMs can share similar names. Identify the CI using class-appropriate authoritative fields before comparing source-specific values. Apply IRE duplicate-prevention rules to resolve the stable VM identity first; a separate reconciliation decision determines which integration may update that CI’s attributes. For a multisource discrepancy, document the observed values and timestamps from Discovery, the hypervisor and endpoint inventory; then test the reconciliation decision without merging genuinely different infrastructure objects.
Read CMDB 360 as a comparison tool
The CMDB 360 workspace experience documents saved queries for comparing reported records. In the described workspace, Get Records explores CIs supplied by named discovery sources, Find Gap finds CIs seen by one source but not another, and Compare Attribute Values identifies inconsistent reported values across sources or compared with the live CMDB. These are different investigative questions, so an analyst should choose the right query instead of interpreting an empty result generically.
Suppose the virtual platform sees 620 active VMs but the endpoint inventory sees only 560. A Find Gap query can produce candidates that lack the second source. That does not prove sixty agents are broken. Some machines may be intentionally out of scope, newly created, unable to support the agent or already decommissioned in the endpoint system. Join each discrepancy to its source timestamp, class, environment and intended collection policy before triggering remediation. A gap query is a worklist for verification, not a final verdict.
Choose reconciliation priority by attribute and source
Reconciliation rules distinguish source authorization from source recency. A more recent update from an unapproved source should not automatically replace a value supplied by the owner of that field. For example, the asset-management team can manage cost center or ownership while Discovery updates an operating-system version. The desired current CMDB record is formed by a controlled combination rather than by allowing each integration to update the entire row without restrictions.
Test a conflict deliberately. Set the approved technical source to report Linux while an older inventory feed reports Windows for the same intended CI. Verify that the chosen configuration preserves or updates the correct value based on actual rule evaluation, and that the disagreement remains diagnosable. Then switch to an authorized business-owned property and confirm that an untrusted scanner cannot replace its value. Document the actual priority configuration and any fallback when the primary source is silent; do not invent behavior from a generic diagram alone.
Understand when data-source rules should prevent creation
Reconciliation is not the only control. In supported classes, IRE data-source rules can prevent a source from creating a brand-new CI while allowing it to contribute authorized updates to existing records. This is useful when a low-confidence feed contains helpful supplementary attributes but not reliable identifiers for creating distinct infrastructure objects. Without a creation boundary, an endpoint inventory can flood the CMDB with temporary records that will never align with the canonical discovered items.
The hospital might allow its endpoint tool to report antivirus state on established servers but require Discovery or a controlled cloud connector to create server CIs. Simulate a payload for an unknown server and a payload for an existing known server. The expected outcomes differ: the first should not create an unapproved record, and the second may update only authorized fields. Check the engine’s reported reason for each outcome, because a blocked insert and a validation error can look similar in a downstream dashboard.
Compare timestamps without confusing time with truth
Every observation should carry a collection timestamp and provenance. A timestamp tells when a source recorded a property; it does not prove the property is accurate or that it should be permitted to overwrite the current CMDB value. Clock skew, sync delays, cached inventory responses and bulk imports can cause a newer ingestion event to contain older observations. Define whether freshness is based on source observation time, update arrival time or an approved collection cycle.
For a frequently changing VM power state, a five-minute-old cloud report may be sufficient; for a supplier’s assigned cost center, an authorized financial record may remain valid much longer. Establish expected latency separately for each field group and monitor connectors that fall outside those windows. A CMDB 360 difference discovered during an outage can be evidence of a failing feed rather than a mistaken CMDB design. Investigate before broadening permissions or resetting priority rules.
Use saved queries to target a measurable reconciliation backlog
Build three synthetic comparisons: an overlapping source set, a source-only set and a disputed-attribute set. Each query should have an owner, a fixed time window, explicit classes and an expected kind of result. Record confirmed false positives and discrepancies that require source remediation. A collection of saved CMDB 360 queries becomes useful when it distinguishes business-significant exceptions from ordinary differences in data coverage, not when it merely counts large numbers of rows.
For example, measure only production database servers that support a critical patient scheduling service, then compare the technical platform feed with the configuration records used by incident teams. Verify a sample of differing operating-system versions and missing ownership values against the authoritative source. Use the findings to alter the ingestion or governance contract, rerun the query and check whether the exceptions were genuinely resolved. Do not improve a chart by hiding the class or excluding entire sources without review.
Test a multisource implementation as one data product
An acceptance plan should include identical identifiers from two feeds, conflicting attribute values, missing primary source, source with no create authority, stale observation, and two distinct machines sharing a friendly name. Check both the resulting CI and its source history. A passing result proves the appropriate record is preserved, approved attributes are updated and uncertainty can be investigated. A query returning zero discrepancies after a rule change is not enough if the change accidentally discarded source evidence.
One particularly revealing audit checks two sources against a known decommissioned resource. A cloud account may have deleted the instance, while an endpoint tool still retains a historical registration and a monitoring platform shows a stale alert. None of those observations alone establishes whether the CMDB CI should be deleted. Record the timestamp and purpose of each feed, check the current system of record, and initiate a lifecycle review before changing serving-state data. Then rerun the three comparison query types and confirm their new outputs agree with the approved ownership model. The test rewards correct classification of evidence, not merely choosing the most recently updated cell.
The end result is more than a merge algorithm. A reliable CMDB records one business-relevant configuration identity while acknowledging that different platforms can observe different aspects of it. CIS-DF candidates should explain which rule prevents a duplicate, which source controls an attribute and how CMDB 360 reveals missing or inconsistent observations. That combination lets teams trust the live CMDB without pretending every integration always agrees.