Reconciliation Rules — Which Source Wins When They Disagree
You now understand how IRE identifies existing CIs (Phase 1). Once identified,
Phase 2 begins: Reconciliation. Multiple sources — Discovery, SGC, manual entry,
custom integrations — may all have a value for the same CI field. Reconciliation
Rules define which source is authoritative for each field. This topic explains
how to configure and troubleshoot these rules.
Imagine three different tools all know about the same server and send updates to IRE:
Discovery finds the server has cpu_count=8 (it scanned the live OS)
AWS SGC says cpu_count=4 (the instance type says 4 vCPUs)
Old CMDB spreadsheet import says cpu_count=2 (from a 3-year-old inventory)
Without a rule, the last one to run wins. If the spreadsheet import runs Monday morning,
your production CMDB says cpu_count=2 even though the actual server has 8 CPUs.
That's wrong data poisoning your CMDB.
Reconciliation Rules solve this by explicitly designating which source is authoritative
for each field. Once a source is authoritative, only that source can update that field.
Other sources' values are ignored — even if they run after the authoritative source.
⚖️
Analogy — Reconciliation Like Editorial Authority
A news organization has multiple contributors: beat reporters, wire services, and
freelancers. They all submit content about the same story. But there are rules:
the staff reporter's version of local facts is authoritative. The wire service
is authoritative for international context. The editor-in-chief can override everyone.
A freelancer can't override the staff reporter's facts just by submitting later.
IRE Reconciliation Rules are the editorial authority structure for your CMDB fields.
Section 2
Anatomy of a Reconciliation Rule
A Reconciliation Rule is a configuration record in
ServiceNow that defines: for CI class X and field Y, which data source has
authority to write values?
Navigate to Configuration → CMDB Identification and Reconciliation →
Reconciliation Rules to view and modify them.
Key Components
Component
What It Does
Example
CI Class
Which CI type this rule applies to
cmdb_ci_server (applies to all servers)
Applies to child classes
Whether the rule cascades to subclasses
If checked, also applies to cmdb_ci_linux_server
Attribute
Which field on the CI the rule controls
cpu_count
Source Priority
Ordered list of sources by trust level for this field
Manual > ServiceNow > AWS SGC > Legacy Import
Staleness Period
How long since a source's last update before its value is considered stale
60 days — after that, a lower-priority source can override
The CMDB Data Source Priority Table
Reconciliation is controlled by the CMDB Data Source Priority
configuration. Think of it as a master ranking of sources. This table is separate
from Reconciliation Rules — it sets the global source ranking, while Reconciliation
Rules override it per-field when needed.
Default global ranking (customizable):
Manual Entry — highest trust; a human deliberately set this
ServiceNow (Discovery) — live active scan directly from device
Service Graph Connectors — API-sourced from cloud/monitoring providers
Orchestration — automated workflows
Other integrations — import sets, third-party tools
Section 3
How IRE Makes Reconciliation Decisions — Step by Step
When IRE has identified an existing CI and is ready to update it with incoming data,
it evaluates each field in the incoming payload:
↓
Input
Incoming Field Value
IRE receives a field update from an identified CI: cpu_count = 8, source = Discovery. For each field in the payload, IRE runs the reconciliation decision chain below.
1
Rule Lookup
Does a Reconciliation Rule Cover This Field?
IRE checks: is there a Reconciliation Rule for cmdb_ci_linux_server.cpu_count? If yes, use its source priority ordering. If no, fall back to the global CMDB Data Source Priority list.
Rule Exists
Use Field-Specific Priority
The Reconciliation Rule defines a priority order for this field (e.g., Discovery > SGC > Manual).
No Rule
Use Global Priority
Falls back to the global CMDB Data Source Priority table, which ranks all sources for all fields.
2
Source Comparison
Rank Incoming Source vs. Current Source
What source last set cpu_count on the existing CI? Current value: cpu_count=6, set by SGC 30 days ago. Is Discovery ranked higher than SGC for this field?
Incoming Wins
Discovery > SGC
Discovery is authoritative for cpu_count. Proceed to staleness check.
Current Wins
Field Ignored
Current source ranks higher. Incoming value is discarded — existing value preserved.
3
Staleness Check
Is the Current Value Past Its Staleness Period?
Even if the incoming source has lower priority, a stale current value can be overwritten. If the Reconciliation Rule's staleness period has elapsed since the last update, lower-priority sources are allowed to write.
Not Stale
Standard Write
Value is fresh. Discovery wins on priority — write cpu_count = 8.
Stale
Lower Source Can Write
Staleness period expired — even a lower-priority source may update this field.
✓
Result
Field Written to CMDB CI
Discovery wins: cpu_count is updated to 8. The CI's discovery_source and last-update metadata are stamped with Discovery as the authoritative source.
The Role of Staleness
Reconciliation Rules include a Staleness Period setting.
This defines how many days a source's value stays "fresh." After the staleness period
expires, even a lower-priority source can overwrite that field.
Why staleness matters: Discovery may be authoritative for cpu_count, but if Discovery
hasn't scanned a server in 90 days (maybe it went offline temporarily), the value
becomes stale. A more current SGC value should then be allowed to update it.
Without staleness, a single Discovery scan could lock in a field value forever even
if Discovery never runs again.
⚠
Exam Trap — Staleness Is Per Field, Not Per CI
Each field tracks its own staleness independently. A CI could have cpu_count
marked as fresh (Discovery ran 10 days ago) but manufacturer marked as stale
(the source that set manufacturer hasn't run in 90 days). Fields don't all
go stale at the same time.
Section 4
Field Ownership Modes
Reconciliation Rules support different ownership modes that control how strictly
a source "owns" a field:
Mode
Behavior
Use Case
Fully Authoritative
Only this source can set this field. All other sources' values for this field are ignored, period.
Business fields (owned_by, cost_center) that only ServiceDesk sets and no tool should override
Priority-Based
Highest-priority source that provides a value wins. Lower-priority sources ignored if higher one has already set the field.
Technical fields (cpu_count, ip_address) where Discovery is best but SGC is acceptable fallback
First-in Wins
Whichever source first sets a value "claims" the field. Later sources cannot overwrite unless the first source's value goes stale.
Set-once fields like serial_number where manual entry wins if set, otherwise Discovery
💡
Key Concept — Protect Manual Fields from Automated Sources
One of the most common Reconciliation Rule configurations: marking business fields
(owned_by, department, support_group, cost_center) as "Manual Entry Fully Authoritative."
This means Discovery and SGC cannot overwrite these fields even though they may
appear in the device scan output. Otherwise, a bad Discovery run could blank out
the business ownership fields of hundreds of CIs.
Section 5
Practical Field Authority Configuration
Here's how typical organizations configure field authority in a multi-source CMDB.
This table is a real-world example of which source is authoritative for which fields:
CI Field
Authoritative Source
Why
serial_number
ServiceNow Discovery
Discovery reads it directly from the hardware
cpu_count
ServiceNow Discovery
Live OS scan is more accurate than API-reported vCPUs
ram
ServiceNow Discovery
Live OS scan; SGC reports allocated memory, not installed
Cloud topology attribute; only the cloud provider knows this
owned_by
Manual Entry
Business ownership decided by humans, not tools
cost_center
Manual Entry
Finance-assigned, must not be overwritten by automation
support_group
Manual Entry
Support assignment is a business decision
environment (prod/dev)
Manual Entry or Orchestration
Environment tag is set during provisioning and should be stable
💡
Tip — "Who Knows Best?" Is the Right Question
For every field in your CMDB, ask: "Which source has the most accurate, up-to-date
knowledge of this specific piece of information?" That source should be authoritative.
Don't assign authority based on which tool is most trusted globally —
a specific source might know one field better than everything else.
Section 6
Reconciliation of Blank and Null Values
An important and often-misunderstood behavior: what happens when an authoritative
source sends a null or blank value for a field?
Default Behavior: Null Does Not Overwrite Non-Null
By default, IRE does not allow a source to "blank out" a field that already has a value,
even if that source is authoritative. This is a protective default — it prevents
sources from accidentally deleting data they don't have.
Example: Discovery is authoritative for serial_number. On Tuesday, the hardware returns
an empty serial (maybe BIOS wasn't responding). By default, IRE keeps the existing
serial_number in the CMDB and doesn't blank it out, even though Discovery returned null.
Overriding the Default: Allow Null Writes
Reconciliation Rules can be configured to allow a source to write null values.
Use this carefully — only when you explicitly want a source to be able to clear a field.
Example use case: when an SGC detects that a cloud resource has been deleted,
it should be allowed to set certain fields to null to indicate the resource no longer exists.
⚠
Warning — Enabling Null Writes Can Cause Data Loss
If you enable "allow null" for an authoritative source and that source ever returns
empty data due to a transient error, it will blank out fields across many CIs.
Always scope "allow null" to specific fields and specific sources, never globally.
Section 7
Source Recency Tracking — The discovery_source and last_discovered Fields
IRE tracks two important metadata fields on every CI that relate to reconciliation:
discovery_source — The name of the
source (tool) that last successfully updated the CI record. Updated every time a source
successfully writes to a CI via IRE.
last_discovered — The timestamp
when the most recent update occurred. Used to calculate staleness for reconciliation.
Per-Field Source Tracking
IRE also tracks source information at the field level (not just the CI level).
This is stored internally and used by Reconciliation Rules to determine which source
last set a specific field and when, for staleness calculations.
The field-level source tracking is not directly visible in standard CI forms,
but can be accessed through the cmdb_ire_identification
table and through the "Source" section that appears on CIs in CMDB Workspace.
CMDB Workspace Source View
In CMDB Workspace (covered in Part 7), you can open any CI and see a "Source" tab
that shows which source is currently authoritative for each field and when it was
last updated. This is the easiest way to understand why a field has a particular value.
⚠
Exam Pattern — discovery_source vs. discovery_source_typediscovery_source = the name of the tool that last updated the CI
(e.g., "ServiceNow", "AWS SGC"). This is a string field on the CI.
Do not confuse with discovery_source_type, which classifies the type
of source (e.g., "Discovery", "API"). The exam may use both terms — know the difference.
Section 8
Troubleshooting Reconciliation — Common Problems
Symptom: A tool keeps overwriting manually-set field values
Root cause: No Reconciliation Rule restricting that field, so global priority applies.
Manual Entry may be globally highest, but if no explicit rule covers this field,
the global default might let automation overwrite manual entries.
Fix: Create a Reconciliation Rule for the class + field, explicitly marking Manual Entry
as "Fully Authoritative" for that field.
Symptom: A field value hasn't updated even though the authoritative source ran
Root causes and checks:
Was the incoming payload missing that field? (IRE skips fields not in the payload)
Did IRE identification succeed? (If identification failed, reconciliation never ran)
Is there a Reconciliation Rule marking a different source as higher priority?
Is the current value set by a higher-priority source that is not yet stale?
Check the IRE Log for the specific CI update event to see reconciliation decisions.
Symptom: A CI shows outdated business fields (owned_by shows a person who left the company)
Root cause: Manual Entry is authoritative, but no one is correcting the data. This is
not an IRE problem — it's a governance and data lifecycle problem. Reconciliation Rules
correctly prevent automation from overwriting manual data, but manual data also needs
a process for review and correction.
Solution: CMDB Health Dashboards (covered in Part 6) and regular data quality reviews
identify stale manual data that needs human correction.
💡
Key Concept — Reconciliation Doesn't Fix Governance Gaps
Reconciliation Rules ensure the right source's value wins when sources conflict.
They cannot fix situations where the "right source" has wrong or stale data.
Manual entry being authoritative for owned_by only helps if humans maintain
that data. Automation handles accuracy for technical fields; humans must maintain
accuracy for business fields. CMDB governance (Part 6) covers how to enforce this.
Exam Quick Reference
Reconciliation Rules — Key Facts
Reconciliation Rule = configuration that assigns source authority per field per CI class.
Authoritative source wins regardless of when it ran. Last-write-wins is eliminated.
Global priority order (default): Manual > Discovery > SGC > Orchestration > Other. Customizable per field.
Staleness Period = how long a source's value stays fresh. After expiry, lower-priority sources can overwrite.
Staleness is per-field, not per CI. Each field tracks its own freshness independently.
Null values don't overwrite by default. Must explicitly enable "allow null" if a source should be allowed to blank a field.
Manual Entry should be fully authoritative for business fields (owned_by, cost_center, support_group).
discovery_source field = which tool last successfully updated the CI. String field on CI record.
CMDB Workspace Source tab shows which source is authoritative per field — best UI for investigating reconciliation decisions.
IRE Log = diagnostic starting point for reconciliation issues alongside identification issues.
Term Grid
Reconciliation Rule
IRE configuration that defines which data source is authoritative for a specific CI field. Overrides global CMDB Data Source Priority for that specific field.
CMDB Data Source Priority
Global ranking table of data sources by trust level. Default order: Manual > Discovery > SGC > Other. Applied when no field-specific Reconciliation Rule exists.
Staleness Period
Number of days a source's field value stays "fresh." After this period, lower-priority sources are allowed to overwrite the value even if the higher-priority source is normally authoritative.
Fully Authoritative
A reconciliation ownership mode where only one source can ever write to a field. All other sources' values are ignored, regardless of priority ranking.
discovery_source
Field on CI record recording which tool last successfully updated the CI via IRE. Examples: "ServiceNow", "AWS Service Graph Connector". Used for auditing and reconciliation calculations.
Allow Null Write
Optional Reconciliation Rule setting that permits an authoritative source to blank out a field value. Off by default — must be explicitly enabled for specific use cases like resource deletion detection.
Exam Checkpoint
Practice Questions
Click any question to reveal the answer and explanation.
1. An IT manager manually sets owned_by="Jane Smith" on a CI in the CMDB. That evening, Discovery runs and the CI payload includes owned_by="" (blank). The next morning, the manager finds owned_by is still "Jane Smith." Which IRE behavior explains this?
A) Discovery is blocked from updating business fields by default
B) Reconciliation Rules mark Manual Entry as authoritative for owned_by, AND the default behavior does not allow null values to overwrite non-null values
C) Discovery did not include owned_by in its payload at all
D) The manager's change was cached and not yet committed to the CMDB
💡 Two IRE behaviors interact here — source authority AND null handling.
Answer: B — Two IRE behaviors protect the field. First, Reconciliation Rules typically mark Manual Entry as fully authoritative for owned_by, meaning Discovery's value would be ignored regardless. Second, even if Discovery were authoritative, the default "null does not overwrite non-null" behavior would prevent the blank value from clearing "Jane Smith." Both protections work together in this scenario.
2. Discovery is configured as the authoritative source for the ip_address field on cmdb_ci_server. A Reconciliation Rule sets a Staleness Period of 30 days. Discovery ran 45 days ago (unusual outage). An SGC now sends a new ip_address value. What happens?
A) The SGC value is ignored because Discovery is always authoritative regardless of staleness
B) IRE creates a conflict alert and doesn't update the field
C) The SGC value overwrites the ip_address because Discovery's value has passed the 30-day staleness period
D) IRE rejects the SGC payload until Discovery runs again
💡 What does the Staleness Period allow lower-priority sources to do?
Answer: C — Staleness Period exists precisely for this situation. If the authoritative source (Discovery) hasn't updated a field within the staleness window (30 days), that field is considered stale. A lower-priority source (SGC) is then allowed to update it. After 45 days without a Discovery update, ip_address is stale, and the SGC value is accepted. This prevents old, potentially incorrect data from being permanently locked in by an authoritative source that stopped running.
3. An administrator notices that the instance_type field on AWS VM CIs in the CMDB always shows data from Discovery (e.g., "t2.micro" derived from CPU count), not from the AWS SGC (which returns the actual EC2 instance type "t2.micro"). The AWS SGC is actually running successfully. What is likely wrong?
A) The AWS SGC is not configured to provide instance_type in its payload
B) A Reconciliation Rule marks ServiceNow Discovery as authoritative for instance_type, overriding the AWS SGC's value
C) The cmdb_ci_aws_ec2_instance class does not have an instance_type field
D) IRE processes Discovery first so its value always wins
💡 Which Reconciliation Rule configuration would cause an SGC to lose to Discovery for a specific field?
Answer: B — If a Reconciliation Rule marks Discovery as authoritative for instance_type, then even though the AWS SGC provides a more appropriate value (since instance_type is a cloud-native concept), Discovery's derived value wins. The fix is to modify the Reconciliation Rule for instance_type to make the AWS SGC authoritative (or higher priority than Discovery) for this field specifically. This illustrates why field-level source authority configuration matters.
4. A company runs an Import Set from a 3-year-old CMDB spreadsheet. After the import, many CI fields that were correctly set by Discovery are now showing old values from the spreadsheet. What configuration would have prevented this?
A) Scheduling Discovery to run after every Import Set
B) Configuring Reconciliation Rules to give the Import Set source lower priority than Discovery for those technical fields
C) Disabling Import Sets from using IRE
D) Setting the Import Set's Transform Map to skip fields that already have values
💡 Reconciliation Rules define which source wins. Who should win for technical fields like cpu_count and ip_address?
Answer: B — Reconciliation Rules are exactly designed for this scenario. If Discovery is ranked higher than the Import Set source for technical fields (cpu_count, ip_address, serial_number, etc.), then even when the Import Set runs, its values for those fields will be ignored in favor of Discovery's more current and accurate values. The Import Set would still be able to update fields it IS authoritative for (like contract numbers or custom attributes).
5. An administrator uses CMDB Workspace to investigate why a CI's os_version field shows an outdated value. Where in CMDB Workspace would they find which source last set that field and when?
A) The Reconciliation Rules configuration form
B) The CI's "Source" tab in CMDB Workspace, which shows per-field source and timestamp
C) The Discovery Status record for the last Discovery run
D) The cmdb_ire_event log filtered by field name
💡 CMDB Workspace has a specific view for per-field source attribution.
Answer: B — CMDB Workspace provides a Source tab on each CI record that shows field-level source attribution: which source last set each field, and when. This is the easiest and most direct way to investigate why a field has a specific value. It's more efficient than filtering the cmdb_ire_event log (D), though that log provides more detailed history of all update decisions.
Exam Checkpoint
Practice Questions
4 questions · Select an answer to see the explanation immediately.
Reconciliation Rules Quiz1 / 4
An IT manager manually sets owned_by="Jane Smith" on a CI. That evening, Discovery runs with owned_by="" (blank) in the payload. The next morning, owned_by still shows "Jane Smith." Which IRE behaviors explain this?
💡 Explanation
B is correct. Two IRE behaviors protect the field simultaneously. First, Reconciliation Rules typically make Manual Entry fully authoritative for owned_by — Discovery's value is ignored regardless. Second, even if Discovery were authoritative, the default "null does not overwrite non-null" behavior prevents a blank value from clearing "Jane Smith." Both protections ensure human-set business attributes aren't corrupted by automated tool payloads.
Discovery is the authoritative source for ip_address with a 30-day Staleness Period. Discovery hasn't run in 45 days due to an outage. An SGC now sends a new ip_address value. What happens?
💡 Explanation
C is correct. Staleness Period exists precisely for this situation. After 45 days without a Discovery update, the ip_address field is considered stale (past the 30-day window). A lower-priority source (SGC) is then allowed to update it. This prevents old, potentially incorrect data from being locked in permanently when the authoritative source stops running. Staleness Period is a safety valve that keeps data current even when the primary source is unavailable.
A legacy CMDB spreadsheet import consistently overwrites correct Discovery-sourced cpu_count values with outdated data. What is the proper fix using IRE?
💡 Explanation
B is correct. Reconciliation Rules are the correct solution. By making Discovery the authoritative source for cpu_count (higher priority than the Import source), IRE will ignore the Import's cpu_count value and preserve Discovery's accurate value. The Import can still update fields it IS authoritative for (like contract numbers or custom attributes). This is exactly the scenario Reconciliation Rules are designed to solve — preventing low-quality sources from overwriting high-quality data.
The instance_type field on AWS EC2 CIs always shows a value derived from Discovery (e.g., inferred from CPU count) rather than the actual EC2 instance type from the AWS SGC. Both sources run successfully. What is the likely cause?
💡 Explanation
B is correct. If a Reconciliation Rule marks Discovery as authoritative for instance_type, Discovery's derived value wins over the AWS SGC's native value, even though the SGC has better data for this cloud-specific field. The fix is to update the Reconciliation Rule to make the AWS SGC the authoritative source for instance_type — since instance_type is a cloud-native concept, the cloud provider's API data is more reliable than Discovery's inference.