Identification and Reconciliation: When ServiceNow Has More Than One Version of the Truth
Here's a fun CMDB problem.
Your company has a server named WEB01.
Discovery knows about it.
Your cloud platform knows about it.
Your asset management system knows about it.
Maybe an old inventory system knows about it too.
And, because this is ServiceNow and somebody always has a spreadsheet somewhere, there's probably a spreadsheet that knows about it as well.
Now all of those sources send information into ServiceNow.
They don't necessarily agree.
One says the server has 16 GB of memory.
Another says 32 GB.
One says Windows Server 2019.
Another says Windows Server 2022.
One source uses a particular hostname.
Another identifies the machine using a serial number.
So now we have a problem.
ServiceNow needs to answer two very important questions:
Which existing CI does this incoming information belong to?
And:
If multiple sources provide different information about that CI, which information should ServiceNow accept?
Those are the problems that Identification and Reconciliation are designed to address.
And once you understand those two problems separately, a lot of the CIS-DF terminology starts making considerably more sense.
Identification Comes First
Let's start with the first question.
An external system sends information about a server.
ServiceNow needs to figure out whether that information belongs to an existing CI or whether it represents something new.
Suppose ServiceNow already contains:
WEB01
Now a discovery process reports:
WEB01
You don't want ServiceNow to blindly create another CI.
You want it to recognize:
"Ah. That's the CI we already know about."
This is identification.
The basic idea is matching incoming data to the correct existing CI.
If the match succeeds, the existing CI can be updated.
If no appropriate match is found, ServiceNow may create a new CI, depending on the process and rules involved.
That sounds simple.
It gets considerably more interesting when names aren't reliable.
Names Aren't Always Enough
Imagine two different systems report:
Server Name: WEB01
That sounds like an easy match.
But what if two different environments both have a server called WEB01?
You might have:
WEB01 in production.
WEB01 in development.
WEB01 in a test environment.
Suddenly, the name alone isn't enough.
ServiceNow needs more reliable ways to determine identity.
That's why identification can involve things such as:
-
Serial numbers
-
Asset tags
-
Hardware identifiers
-
Hostnames
-
IP addresses
-
Other identifying attributes
The exact attributes used depend on the CI class and the identification rules configured for it.
The important concept is that identification is about determining which CI an incoming record represents.
Identification Rules
This is where identification rules come into play.
Identification rules define how ServiceNow should determine whether incoming information matches an existing CI.
Imagine the incoming data contains a serial number.
If that serial number uniquely identifies a CI, ServiceNow can use it as part of the identification process.
The rules can establish which identifying attributes or combinations of attributes should be considered.
The goal is to avoid situations where ServiceNow says:
"Well, the names look similar, so let's just create another record."
That is exactly the kind of behavior that can turn a CMDB into duplicate-CI city.
Why Multiple Identifiers Can Matter
Suppose a server has:
Hostname: WEB01
Serial number: SN123456
IP address: 10.10.10.50
Any of these might provide useful information.
But they don't necessarily have the same reliability in every environment.
An IP address can change.
A hostname might be reused.
A serial number may be much more stable for a physical device.
This is why identification isn't simply:
"Find a field that matches."
It's about using the identification logic appropriate for that CI class and environment.
The objective is confidence that the incoming information belongs to the correct CI.
What Happens When No Match Exists?
Let's say ServiceNow receives information about:
APP27
It checks the relevant identification rules.
Nothing matches an existing CI.
Now what?
If the process permits it, ServiceNow can create a new CI representing APP27.
That's an important distinction.
Identification isn't just about finding existing records.
It also helps determine whether incoming data represents something that ServiceNow doesn't currently know about.
So the process is essentially asking:
"Do I already know this thing?"
If yes, associate the incoming data with the existing CI.
If no, the appropriate process may create a new CI.
Now We Have a Second Problem
Let's say ServiceNow successfully identifies WEB01.
Great.
We know which CI we're talking about.
But now Discovery says:
Operating system: Windows Server 2022
The inventory system says:
Operating system: Windows Server 2019
The asset system says:
Operating system: Windows Server 2016
Which one wins?
Identification solved one problem.
It did not solve this one.
We know all three sources are talking about WEB01.
Now we need to decide which source is allowed to provide or update the information.
That's where reconciliation comes in.
Reconciliation Is About Who Gets to Update What
Reconciliation helps determine which data sources are allowed to update CI information when multiple sources provide data.
This is where the idea of data precedence becomes important.
Not every source should necessarily have equal authority.
For example, an organization might decide that:
-
Discovery is authoritative for certain technical attributes.
-
An asset management system is authoritative for financial or ownership information.
-
Another system is authoritative for a particular business attribute.
The important thing is that authority can depend on what information is being updated.
The system that is best at identifying a server may not be the system that is best at knowing who owns it.
That distinction is extremely important.
One Source Does Not Have to Be the Authority for Everything
This is an easy mistake to make.
Imagine the organization has:
Discovery
Excellent at finding technical infrastructure.
Asset Management
Excellent at tracking purchasing and ownership information.
Cloud Management
Excellent at knowing about cloud resources.
Which one should be considered authoritative?
The answer may be:
It depends on the attribute.
Discovery might be trusted for a server's operating system.
Asset Management might be trusted for purchase information.
A cloud platform might be trusted for cloud-specific attributes.
Trying to declare one system the universal source of truth for every field isn't necessarily the best approach.
Reconciliation allows organizations to establish more nuanced control over who can update what.
Data Precedence
This is where data precedence becomes important.
Suppose two data sources both provide a value for the same attribute.
The organization can establish which source has priority.
For example:
Discovery has higher precedence than Inventory for operating system information.
Inventory has higher precedence than Discovery for a particular ownership attribute.
Now imagine Inventory sends:
Operating system: Windows Server 2019
Discovery sends:
Operating system: Windows Server 2022
If Discovery has higher precedence for that attribute, the Discovery value should take priority.
This prevents lower-authority sources from casually overwriting information provided by a more trusted source.
A Useful Way to Think About IRE
The Identification and Reconciliation Engine, or IRE, brings these ideas together.
When data comes into the CMDB, IRE helps process that data according to identification and reconciliation logic.
A simplified way to think about it is:
Identification
"Which CI is this?"
Reconciliation
"Is this source allowed to update this CI's information?"
Those questions are related, but they are different.
And that distinction is one of the most useful things to understand for the exam.
Identification Does Not Mean "Update Everything"
Suppose Discovery correctly identifies WEB01.
That doesn't mean Discovery should automatically overwrite every field on the CI.
Maybe Discovery knows:
-
Hostname
-
IP address
-
Operating system
-
Installed software
But it doesn't know:
-
Business owner
-
Cost center
-
Purchase date
-
Financial information
Even if Discovery can identify the CI perfectly, that doesn't make it authoritative for all of those attributes.
Identification answers:
Which CI?
Reconciliation helps answer:
Which source is allowed to update which information?
What Happens When a Lower-Priority Source Tries to Update Something?
Suppose Discovery is the authoritative source for an operating system attribute.
An old inventory system sends an update saying the server is running an older operating system.
The inventory system may successfully send the data into ServiceNow.
But that doesn't necessarily mean the existing CI should be updated with that value.
Reconciliation rules can prevent a lower-priority source from overwriting information provided by a higher-priority source.
This is one of the major benefits of having reconciliation controls.
Without them, every new data feed could potentially overwrite information from a source the organization trusts more.
Why This Matters So Much
Think about what happens in a large enterprise if there are no controls.
System A sends:
Windows 2022.
System B sends:
Windows 2019.
System C sends:
Windows 2016.
System D sends:
Unknown.
Whichever system happens to run last could potentially change the value.
The CMDB would become a constantly shifting collection of conflicting information.
That isn't useful.
The goal is for the CMDB to reflect the organization's agreed understanding of the environment, not simply whichever system shouted last.
The Duplicate CI Problem
Identification is particularly important because duplicate CIs can cause problems far beyond having two records with similar names.
Imagine ServiceNow has:
WEB01
and
WEB01-NEW
but both actually represent the same physical server.
Now one application relationship points to WEB01.
Another points to WEB01-NEW.
An incident is associated with one.
Discovery updates the other.
Asset information is associated with one.
Now you've split the truth about a single piece of infrastructure across multiple records.
That can create confusion everywhere else.
Relationships become unreliable.
Reports become inaccurate.
Impact analysis can become misleading.
Data quality deteriorates.
This is why proper identification is one of the foundations of a healthy CMDB.
Identification and Reconciliation Are Different Problems
This distinction is worth slowing down for.
Imagine an incoming record arrives for a server.
The first question is:
"Which CI is this?"
That's identification.
Once ServiceNow knows the CI, the next question is:
"Should this source be allowed to change the information on that CI?"
That's reconciliation.
You can get the first question right and the second question wrong.
For example:
ServiceNow correctly identifies WEB01.
But an untrusted source overwrites the operating system information.
The identification worked.
The reconciliation didn't produce the desired result.
Understanding that difference will help enormously with scenario-based questions.
A Realistic Example
Let's say your organization has three systems feeding ServiceNow.
Discovery
Reports infrastructure configuration.
Asset Management
Tracks ownership, financial information, and asset details.
Cloud Platform
Reports cloud-specific configuration.
A server is discovered.
Discovery provides:
Hostname: WEB01
Operating system: Windows Server 2022
IP address: 10.10.10.50
Asset Management provides:
Owner: Infrastructure Team
Purchase information: Internal record
Cloud Platform provides:
Cloud account information
Region: us-east-1
The ideal result isn't to pick one system and throw away the other two.
The ideal result is to allow each source to contribute the information it is responsible for.
That's the power of having a structured approach to reconciliation.
Why Authoritative Sources Matter
You will often encounter the concept of an authoritative source.
An authoritative source is a source that an organization has determined should be trusted for particular information.
This is a governance decision as much as a technical one.
For example, the organization might decide:
"The HR system is authoritative for employee information."
"Discovery is authoritative for server configuration."
"Asset Management is authoritative for ownership and financial information."
Now everyone has a clearer understanding of where particular information should come from.
This helps prevent the classic enterprise problem where five systems all claim to be the source of truth.
IRE Isn't Just a Duplicate Detector
Another misconception is thinking that IRE exists primarily to prevent duplicates.
Preventing duplicate CIs is certainly an important outcome of proper identification.
But IRE is involved in more than simply asking whether a duplicate record exists.
It helps process incoming data using identification and reconciliation logic.
That means the system is considering:
-
What CI does this data represent?
-
Should an existing CI be updated?
-
Is a new CI appropriate?
-
Is this source allowed to update the relevant information?
-
Are there reconciliation rules that affect the update?
That is much broader than simple duplicate detection.
What About Relationships?
IRE-related processing can also matter when incoming data includes relationships.
Imagine Discovery finds:
WEB01 runs on Server01.
Later, another source provides a conflicting relationship.
Again, the organization needs rules around how configuration information and relationships should be handled.
A CMDB isn't just a collection of isolated records.
Relationships are part of the configuration data too.
That means maintaining trustworthy relationships is just as important as maintaining trustworthy CI attributes.
A Common Exam Trap
Here's a scenario that could easily fool someone:
"An organization wants to prevent duplicate configuration items when information about the same server arrives from multiple data sources."
The answer isn't necessarily:
"Use reconciliation."
The problem being described is primarily identification.
The organization needs to determine that the incoming records represent the same CI.
Now change the scenario:
"An organization wants to prevent a lower-priority data source from overwriting an attribute provided by an authoritative source."
Now you're looking at reconciliation.
Same general area.
Different problem.
That's exactly the sort of distinction worth watching for in certification questions.
Another Exam Trap: The Latest Data Isn't Automatically the Best Data
Imagine:
Discovery reports Windows Server 2022.
An older inventory system reports Windows Server 2019.
Someone might think:
"Well, whichever arrived most recently must be correct."
Not necessarily.
Recency and authority aren't the same thing.
A source can provide information yesterday that is still less trustworthy than information from an authoritative source.
The organization needs rules that reflect which sources should be trusted for particular data.
That's why reconciliation and precedence exist.
When Identification Goes Wrong
Suppose an incoming record cannot be matched confidently to an existing CI.
Creating a new CI might be appropriate.
But if the identification rules are poorly designed, you could end up with duplicates.
For example:
Existing CI:
WEB01
Incoming record:
WEB01
But the system doesn't have enough reliable identifying information to establish that they're the same.
If a new CI is created anyway, you now have duplicate or potentially duplicate information.
This is why identification rules need to be designed carefully.
Too little identifying information can create duplicates.
Poorly chosen identifiers can produce incorrect matches.
The goal is to strike the right balance.
When Reconciliation Goes Wrong
Reconciliation problems look different.
Suppose ServiceNow correctly identifies WEB01.
But now five different sources are allowed to overwrite the same attribute.
The value changes repeatedly.
Nobody knows which one is correct.
The problem isn't that ServiceNow failed to recognize WEB01.
It recognized WEB01 perfectly.
The problem is that the organization hasn't established appropriate authority over the data.
That's a reconciliation and governance problem.
The Connection to Data Quality
Now you can see why this topic matters so much to the overall CIS-DF exam.
Bad identification can create duplicate CIs.
Bad reconciliation can create conflicting or incorrect attributes.
Both problems reduce data quality.
And once the CMDB contains unreliable information, everything that depends on it becomes less trustworthy.
Reports can be wrong.
Impact analysis can be wrong.
Incident investigations can be harder.
Change planning can be affected.
Service relationships can become misleading.
This is why identification and reconciliation aren't just obscure technical mechanisms.
They are part of maintaining a useful CMDB.
My Favorite Two Questions
When you're staring at a CIS-DF scenario and it starts talking about multiple data sources, stop and ask yourself two questions.
Question one:
"Does ServiceNow know which CI this data belongs to?"
If that's the problem, you're thinking about identification.
Question two:
"ServiceNow knows the CI, but which source should be allowed to change the information?"
If that's the problem, you're thinking about reconciliation.
Those two questions will get you surprisingly far.
The Big Picture
By this point, the overall flow should look something like this in your head.
Data comes into ServiceNow from somewhere.
ServiceNow needs to determine what that data represents.
If it represents an existing CI, the incoming information needs to be associated with that CI.
If it represents something new, a new CI may need to be created.
If multiple sources provide information about the same CI, ServiceNow needs to determine which sources should be trusted for the relevant data.
That's where identification and reconciliation become critical.
The result we're looking for isn't simply:
"ServiceNow has a record."
We're looking for:
"ServiceNow has the right record, with information from the appropriate sources."
That's a much higher standard.
What to Remember
Identification is about determining which CI incoming data belongs to.
Identification rules define how ServiceNow determines whether incoming information matches an existing CI.
Reconciliation is about controlling which sources can update CI information.
Data precedence helps determine which source has priority when multiple sources provide information.
An authoritative source is a source trusted for particular information.
The IRE brings identification and reconciliation logic together when processing CMDB data.
And the big reason any of this matters is simple:
You don't want multiple systems feeding ServiceNow to create multiple versions of reality.
You want ServiceNow to recognize that everyone is talking about the same things and understand which information should be trusted.
Once that happens, the CMDB has a much better chance of representing the environment accurately.
And when the CMDB represents reality accurately, all those fancy ServiceNow processes built on top of it have something much more valuable to work with.