A modern CMDB rarely has one source. Discovery may know operating-system details, a cloud connector may know provider metadata, an asset system may know ownership and lifecycle state, and a security platform may know posture. When those sources report the same CI, the platform needs a deterministic way to decide which source may update each attribute. ServiceNow reconciliation rules provide that control after identification has determined which CI the incoming data represents.<\/p>\n
Reconciliation is therefore a source-authority system. In ServiceNow platform engineering<\/a>, its purpose is not merely to stop unwanted overwrites. It makes data ownership explicit enough that downstream consumers can trust why a field has its current value. A CMDB becomes more reliable when the answer to \u201cwhere did this value come from?\u201d is governed rather than accidental.<\/p>\n ServiceNow supports reconciliation designs that can assign source authority and precedence for attributes, including static and dynamic approaches depending on the implementation. The engineering task is to translate business knowledge about data quality into those rules without creating so many overlapping exceptions that no one can predict which source will win.<\/p>\n Do not begin by ranking entire sources from best to worst. One source can be authoritative for serial number and model while another is authoritative for support group or business owner. Reconciliation should reflect those distinctions. Create a map of critical attributes, candidate sources, expected update frequency, and the reason a source is trusted.<\/p>\n This is a core part of CMDB governance<\/a>. Technical precedence should correspond to organizational ownership. If the asset team is accountable for lifecycle status, a discovery tool should not silently replace that status just because it ran more recently. If discovery is the best evidence for installed operating system, a manually maintained spreadsheet may not deserve equal write authority.<\/p>\n Prioritize attributes that drive automation, service impact, routing, security, compliance, or reporting. Not every descriptive field needs an elaborate rule, but high-consequence data should have a clear owner and a predictable update path.<\/p>\n Reconciliation applies to an identified CI. If the incoming payload creates a duplicate instead of matching the existing record, source-precedence rules may protect each duplicate perfectly while the CMDB remains wrong. This is why identity and authority need separate controls that are reviewed together.<\/p>\n The data-foundation approach in ServiceNow CMDB design<\/a> connects class modeling, identification, reconciliation, relationships, and health. A source onboarding review should ask first whether the object will match the correct CI and then which attributes it may update. Skipping the first question produces competing records rather than competing values.<\/p>\n When reconciliation appears to \u201cnot work,\u201d confirm that the payload was associated with the expected CI and that the source identity is the one the rules reference. A mismatch in data-source naming or classification can make a correct-looking rule irrelevant to the actual transaction.<\/p>\n Static reconciliation is useful when the organization can state a stable rule such as \u201csource A owns these attributes and outranks source B.\u201d Its strength is predictability. Operators can inspect the precedence and understand why an update was accepted or rejected without reconstructing a changing context.<\/p>\n Keep priorities as simple as the data model allows. A long ladder of sources for each attribute can encode historical compromises that no one still understands. If a source is consistently low quality for a field, consider removing its authority rather than assigning it the lowest of many priorities and hoping higher-priority sources always run.<\/p>\n The concepts in ServiceNow reconciliation<\/a> become operationally useful when source priority mirrors evidence quality. Document the rationale next to the rule set or in the CMDB governance record so a future team can distinguish intentional precedence from arbitrary configuration.<\/p>\n Some environments need precedence that depends on context rather than a fixed source ranking. A source may be trusted only while its data is fresh, for a particular object population, or under conditions that reflect lifecycle state. Dynamic approaches can represent that reality, but they increase the number of possible outcomes and require stronger testing.<\/p>\n Do not use dynamic rules merely to solve one difficult exception. State the general policy first. If the policy cannot be explained without referring to a specific incident, the design may be compensating for source-quality problems that should be fixed upstream.<\/p>\n Monitor the inputs that drive dynamic authority. If freshness, status, or another condition decides which source wins, a defect in that controlling value can redirect ownership across many CIs. The rule should fail in a way that is understood rather than silently granting authority to an unexpected source.<\/p>\n The most visible benefit of reconciliation is preventing a lower-quality source from overwriting trusted data. The less obvious risk is overprotection. A rule can freeze an attribute when the authoritative source stops sending updates, changes its identifier, or no longer owns the object population. Stale high-priority data can be just as damaging as uncontrolled overwrites.<\/p>\n Governance should therefore include source-health and lifecycle review. If an authoritative feed fails for several days, the platform team needs to know whether another source may temporarily take over, whether the data should be marked stale, or whether consumers should be warned that the field is no longer current.<\/p>\n The architecture behind trusted CMDB data<\/a> is not simply \u201cnever let weaker sources write.\u201d It is \u201cmake authority explicit, observe whether the authoritative source is healthy, and change the model deliberately when the real source of truth changes.\u201d<\/p>\n A new Service Graph Connector or integration can introduce a high-volume source with broad attribute coverage. Enabling it without reviewing reconciliation can change thousands of values quickly. Before activation, compare the connector\u2019s mapped attributes with existing source-authority rules and identify where it will create new competition.<\/p>\n Test representative CIs that already have values from current sources. Record which incoming fields are accepted, which are rejected, and which are not governed. Unexpectedly accepted fields may expose a gap in reconciliation. Unexpectedly rejected fields may show that an old source retains authority it no longer deserves.<\/p>\n For ServiceNow CIS-DF<\/a>-aligned work, this is a practical governance checkpoint: ingestion design is not complete until source precedence is intentional. The connector\u2019s technical success should be measured separately from whether the resulting CMDB values are the ones the organization intended.<\/p>\n Reconciliation failures and rejected updates are signals. A rising number of rejected values from a previously healthy source may mean the source mapping changed or precedence no longer reflects reality. Frequent manual corrections can indicate that the governed source is not actually authoritative. Monitoring should reveal these patterns before users lose trust in the CMDB.<\/p>\nStart with an attribute-level source-authority map<\/h3>\n
Identification must succeed before reconciliation can protect anything<\/h3>\n
Static precedence works best when authority is durable and easy to explain<\/h3>\n
Dynamic precedence needs a clear business reason for authority to change<\/h3>\n
Reconciliation should preserve trusted values without blocking legitimate correction<\/h3>\n
Onboard new connectors through a reconciliation impact review<\/h3>\n
Use health and audit data to detect source-authority problems<\/h3>\n