Getting Data Into ServiceNow: Imports, Integrations, and the Many Ways Data Arrives
So you've got a CMDB.
You've got CIs.
You've got relationships.
You've even got CSDM helping everyone agree on what all those things are supposed to mean.
There's just one tiny problem.
Someone has to actually get the data into ServiceNow.
And in a real organization, that can get messy very quickly.
ServiceNow rarely lives in isolation. An organization may already have discovery tools, cloud platforms, monitoring systems, inventory databases, management tools, spreadsheets, third-party applications, and all kinds of other systems that know things about the environment.
ServiceNow needs a way to receive that information.
Sometimes the data comes from another ServiceNow capability.
Sometimes it comes from an external system.
Sometimes someone uploads a file.
Sometimes an integration sends it automatically.
And sometimes, yes, someone still types something into a form.
The CIS-DF exam wants you to understand the different approaches and, more importantly, why a particular approach is being used.
Start With the Source
Before worrying about which ServiceNow feature to use, start with a very basic question:
Where is the data right now?
Suppose your company has an inventory system that already knows about 8,000 laptops.
Those laptop records aren't magically sitting in the ServiceNow CMDB.
They're somewhere else.
Maybe the inventory system exposes an API.
Maybe it can export a CSV file.
Maybe there's an existing connector.
Maybe the organization has another integration platform that can move the data.
The first step in understanding an ingestion scenario is identifying the source.
The source is the system that currently has the information.
ServiceNow is the destination.
Once you know that, you can start thinking about how the two systems are going to communicate.
Not Every Data Source Works the Same Way
Imagine three different situations.
The first system can send JSON through an API every few minutes.
The second system can produce a CSV file once a night.
The third system has a supported ServiceNow connector that can pull information directly.
All three contain useful data.
But the method for bringing that information into ServiceNow could be completely different.
This is why there isn't one magical "import everything" button.
The appropriate method depends on the source, the type of data, the frequency of updates, the integration capabilities available, and what ServiceNow needs to do with the information.
Import Sets: The Staging Area
One of the important concepts you'll encounter is the Import Set.
Import Sets provide a way to bring external data into ServiceNow and stage it before transforming it into the appropriate target records.
That staging step is important.
Imagine an external system sends a file containing:
-
Hostname
-
IP address
-
Operating system
-
Manufacturer
-
Serial number
The data may not be formatted exactly the way the target ServiceNow table expects.
Maybe the external system calls something "OS Name" while ServiceNow expects a particular field.
Maybe the source has values that need to be converted.
Maybe the incoming records need to be matched against existing records.
You don't necessarily want to dump raw source data directly into the final destination and hope everything works out.
Import Sets provide a place where the incoming data can be handled before it reaches the target.
That's the staging concept to remember.
The Import Set Table
When data comes into an Import Set, it is typically placed into an Import Set table.
Think of this as a temporary or staging representation of the incoming information.
The source data arrives.
ServiceNow has a place to hold it.
Then the data can be processed and transformed into the appropriate target table.
This separation is useful because the source format and the ServiceNow target format don't always match.
The external system doesn't need to understand exactly how ServiceNow stores the final information.
ServiceNow can handle that conversion as part of the import process.
Transform Maps: Turning One Shape Into Another
This is where Transform Maps enter the story.
A Transform Map defines how imported data should be transformed and mapped into a target ServiceNow table.
Suppose the incoming source calls a field:
device_name
But the ServiceNow target uses:
name
The Transform Map can define how the incoming value is mapped to the target field.
It can also support transformations and field mapping logic needed to prepare the data for the destination.
So if you're trying to remember the basic relationship:
Import Set = incoming/staged data
Transform Map = instructions for transforming and mapping that data to the target
The Import Set gets the source information into ServiceNow.
The Transform Map helps determine what happens to that information on its way to the destination.
A Simple Example
Suppose an HR system exports employee information.
The source file might contain:
-
Employee ID
-
First Name
-
Last Name
-
Department
-
Manager
The ServiceNow target table might use different field names and structures.
The Import Set receives the source data.
The Transform Map determines how those incoming fields correspond to fields in the target.
The result is ServiceNow records in the appropriate structure.
The important thing here is that an Import Set isn't itself the final destination.
It's part of the process used to get external data into ServiceNow.
Importing Data Doesn't Mean the Data Is Automatically Good
This is an important distinction.
You can successfully import 50,000 records and still have a terrible CMDB.
Success at ingestion simply means the data made it into the platform.
It doesn't necessarily mean:
-
The records are correct
-
The records are unique
-
The attributes are accurate
-
The relationships are correct
-
The source should have been allowed to update everything
-
The data matches the organization's standards
In other words:
Getting data into ServiceNow and having trustworthy data in ServiceNow are two different problems.
This distinction will come up repeatedly throughout CIS-DF.
Integrations: When Systems Need to Talk
Import Sets are useful, but organizations often need something more continuous than uploading files.
That's where integrations become important.
An integration allows systems to exchange information.
For example, ServiceNow might need to receive information from:
-
A cloud platform
-
An endpoint management system
-
A monitoring platform
-
A security tool
-
An asset management system
-
A third-party business application
Instead of someone manually exporting and uploading data, an integration can automate the exchange.
The exact technology can vary.
ServiceNow supports different integration approaches, including APIs and other integration capabilities.
The important exam concept is recognizing when the scenario calls for automated communication between systems rather than a one-time manual data load.
APIs: Letting Systems Communicate Programmatically
An API, or Application Programming Interface, provides a defined way for software systems to communicate with one another.
Instead of a person opening a spreadsheet and uploading it, another application can make a request to ServiceNow.
For example, an external system might send information about a newly discovered device.
ServiceNow receives the request and processes the information.
That can happen automatically and repeatedly.
This is one reason APIs are so useful in modern IT environments.
Systems don't have to wait for someone to manually move information from one place to another.
They can communicate directly.
For CIS-DF, don't get too caught up in programming details.
The important idea is:
APIs provide a programmatic way for systems to exchange data.
Batch vs. Real-Time Data
Another distinction worth understanding is how frequently data needs to move.
Imagine a system that exports inventory information every night.
That's a batch-style process.
The data is collected, packaged, and processed periodically.
Now imagine a monitoring system that needs to send an update as soon as a critical configuration change occurs.
That may call for a more immediate integration.
Neither approach is automatically better.
It depends on the business requirement.
A nightly inventory update may be perfectly acceptable for one type of information.
A security-related event might need to be processed almost immediately.
When a scenario mentions how frequently information needs to be updated, pay attention.
That detail can help you determine the appropriate integration approach.
Service Graph Connectors
Now we get to a ServiceNow capability that is particularly relevant to CMDB data.
Service Graph Connectors provide a way to bring data from external sources into the ServiceNow CMDB using supported integrations.
This matters because organizations frequently have systems that already contain valuable configuration information.
Instead of building a completely custom integration from scratch for every source, a connector can provide a standardized approach for supported data sources.
Depending on the connector and source, this can help bring information such as configuration items and related data into the CMDB.
The important concept isn't simply memorizing the name.
Think about the problem it addresses:
An external system already knows useful configuration information, and ServiceNow needs that information represented in the CMDB.
That's the territory where Service Graph Connectors become relevant.
Discovery Is Another Way Data Gets There
Discovery is another major source of configuration information.
Rather than relying entirely on another inventory system to tell ServiceNow what exists, Discovery can investigate the environment and identify infrastructure.
Depending on the environment and configuration, Discovery can find things such as:
-
Servers
-
Network devices
-
Applications
-
Virtual machines
-
Databases
-
Other infrastructure components
It can then populate or update configuration information in the CMDB.
This makes Discovery particularly useful when the organization wants ServiceNow to discover technical infrastructure rather than simply importing a static inventory.
Discovery and Importing Aren't the Same Thing
This is an easy place to get confused.
Suppose an organization already has an external inventory database containing a list of servers.
Importing or integrating that information means ServiceNow is receiving data from that external source.
Discovery is different.
Discovery actively gathers information about the environment.
That difference matters.
If the scenario says:
"An organization wants ServiceNow to automatically discover servers and their configuration information."
That's pointing you toward Discovery.
If the scenario says:
"An organization already has server information in another system and wants to bring it into the CMDB."
Now you're thinking about integration, import, or a connector, depending on the details.
The Data Usually Needs to Be Transformed
External systems don't always use the same terminology or structure as ServiceNow.
One system might store a server's operating system as:
Windows Server 2022
Another might store:
WIN2022
Another might use a numeric code.
The information may represent the same concept while being formatted differently.
This is one reason transformation matters.
ServiceNow needs to turn incoming information into a structure that makes sense inside the platform.
Transformations can include things like:
-
Mapping fields
-
Converting values
-
Formatting data
-
Looking up related records
-
Applying business logic
-
Preparing information for the target table
Again, the goal isn't merely to move bytes from one system to another.
The goal is to create useful ServiceNow data.
What Happens When the Source Has a Different Structure?
Imagine an external inventory system has this:
device_type = 3
That doesn't mean much to a person looking at the ServiceNow record.
ServiceNow may need to translate that value into something meaningful.
Perhaps:
3 = Server
The transformation process can help convert the source representation into the appropriate ServiceNow representation.
This is one of the reasons you shouldn't think of an integration as simply "copy this field to that field."
Real integrations often involve mapping and transformation.
The Same Data Can Arrive More Than Once
Now we're approaching one of the biggest problems in CMDB ingestion.
Suppose Discovery finds WEB01.
Then your cloud connector finds WEB01.
Then your inventory system sends WEB01.
You don't want three CIs.
You want ServiceNow to understand that all three sources are talking about the same configuration item.
That's where Identification and Reconciliation Engine (IRE) becomes extremely important.
IRE is responsible for helping determine which CI an incoming piece of data corresponds to and how that data should be processed.
We'll give IRE its own breakdown later because there is quite a bit to understand there.
For now, remember this:
Ingestion gets information into ServiceNow. Identification and reconciliation help determine what that information means in relation to existing CMDB data.
Those are related problems, but they aren't the same problem.
Why Source Matters
Here's another subtle point that becomes increasingly important as your CMDB grows.
Not every source should necessarily be treated equally.
Imagine three systems reporting a server's operating system.
Your discovery system says Windows Server 2022.
An old spreadsheet says Windows Server 2016.
A manually maintained inventory says Windows Server 2019.
Which source should win?
You need some way to establish which source is authoritative for particular information.
This is part of the broader reconciliation problem.
The ingestion process can successfully bring all three sets of information into the platform.
That doesn't automatically tell ServiceNow which value should be trusted.
This is why data ingestion and data governance are so closely connected.
Don't Forget About Manual Data
Automation is wonderful.
But don't fall into the trap of assuming everything in ServiceNow must be populated automatically.
There are legitimate cases where users need to create or modify information manually.
The important question is whether manual maintenance is appropriate for the type of data involved.
If a server's hostname changes every few months and Discovery already knows the answer, having five different people manually update that information is probably not a great strategy.
You're introducing unnecessary opportunities for inconsistency.
On the other hand, certain business information may not be discoverable automatically and may require human input.
The goal isn't:
Automate everything.
The goal is:
Use the appropriate source and method for the information being managed.
A Quick Comparison
Here's how I'd mentally separate some of the major concepts.
Import Sets
Useful when bringing external data into ServiceNow through an import process and staging that information before it reaches the target.
Transform Maps
Define how imported information is mapped and transformed into the target table.
APIs
Allow systems to exchange information programmatically.
Service Graph Connectors
Provide supported ways to bring external source data into the ServiceNow CMDB.
Discovery
Automatically discovers infrastructure and configuration information from the environment.
These aren't competing features where one is always "better."
They're tools for different situations.
The exam may give you a scenario and expect you to identify which approach fits the requirement.
A Scenario That Looks Simple Until You Think About It
Imagine a company has 20,000 servers.
The infrastructure team already has a management platform containing detailed information about those servers.
The company wants that information available in the ServiceNow CMDB.
There are several possible approaches.
If the management platform has a supported Service Graph Connector, that may be appropriate.
If the organization has built an integration using APIs, that may be appropriate.
If the platform can export data files and the organization wants a scheduled import, Import Sets may be involved.
If the requirement is for ServiceNow itself to discover the infrastructure, Discovery may be appropriate.
The important thing is to read the scenario carefully.
Don't see "servers" and automatically answer "Discovery."
The question is not simply asking:
"What feature can find servers?"
It's asking:
"What is the organization trying to accomplish, and where does the information currently exist?"
That's a much better way to approach these questions.
Why Data Ingestion Is a Foundation
At first glance, importing data might sound like a fairly technical plumbing problem.
But it has a much bigger impact.
If the wrong source is used, the data may be incomplete.
If transformations are wrong, the data may be misrepresented.
If identification is poor, duplicate CIs can appear.
If relationships aren't established, the CMDB may not reflect dependencies.
If sources aren't governed, conflicting information can overwrite good data.
So the ingestion process is really the beginning of a much larger chain.
You aren't just asking:
"How do I get this data into ServiceNow?"
You're asking:
"How do I get the right data into ServiceNow in a way that preserves its meaning and allows the CMDB to remain trustworthy?"
That is a much better question.
My Version
If I had to explain the whole thing while standing in front of a whiteboard, I'd probably start with this:
Your data already exists somewhere.
ServiceNow needs to receive it.
The method depends on where the data lives and how it needs to move.
Import Sets can stage incoming data.
Transform Maps help map and transform it.
APIs let systems communicate programmatically.
Service Graph Connectors can bring supported external data into the CMDB.
Discovery can actively discover infrastructure.
And once that information starts arriving from multiple places, identification and reconciliation become critical.
That's the progression to keep in your head.
One Last Thing: Don't Confuse "Imported" With "Trusted"
This is probably the biggest lesson from this breakdown.
A record appearing in the CMDB doesn't make it correct.
A successful integration doesn't guarantee good data.
A connector doesn't automatically solve duplicate records.
Discovery doesn't mean every discovered attribute is necessarily perfect.
An Import Set doesn't mean the incoming information should automatically overwrite whatever is already there.
Getting information into ServiceNow is only one part of the job.
The next questions are:
What does this data represent?
Which CI does it belong to?
Should this source be allowed to update it?
Can we trust the information?
Those questions lead directly into the next major piece of the CIS-DF puzzle: Identification and Reconciliation.
And that's where things get really fun.