Introduction

A Data Source in ServiceNow defines where external data comes from before that data is loaded into ServiceNow through the Import Set framework. In a real implementation, a data source may represent a CSV file, Excel file, JDBC database, LDAP directory, REST-based source, or another supported integration mechanism. ServiceNow uses the data source together with an Import Set table and Transform Map to move external data into business tables such as Users, Groups, Configuration Items, or custom application tables.

For example, suppose an organization maintains employee information in an HR database but wants ServiceNow to maintain accurate user records. Rather than manually creating thousands of users, an integration can retrieve employee data from the source database, place it into an Import Set staging table, transform the fields, and update the ServiceNow sys_user table.

This pattern is especially useful when the external application cannot directly create records in ServiceNow’s target tables or when the implementation requires validation, transformation, deduplication, and controlled processing before data reaches production tables.

What Is a Data Source in ServiceNow?

A Data Source is a ServiceNow configuration record that tells the platform where and how to retrieve data for an import.

It is important to understand that a Data Source is not the same thing as an Import Set or Transform Map.

The basic architecture is:

External Source → Data Source → Import Set Table → Transform Map → ServiceNow Target Table

For example:

HR Database → JDBC Data Source → Import Set Table → Transform Map → sys_user

The Data Source defines the source and retrieval mechanism. The Import Set table temporarily stages the incoming records. The Transform Map defines how those records should be converted and loaded into the target table. ServiceNow documentation describes the Import Set table as a staging location and the Data Source as the record defining where the import data is obtained.

Data Source vs Import Set vs Transform Map

This separation is important in enterprise projects because it allows the integration team to troubleshoot each stage independently.

Supported Data Source Types in ServiceNow

Modern ServiceNow Import Sets support multiple input mechanisms. Current ServiceNow documentation lists file-based sources and external sources such as JDBC, LDAP, OIDC, ServiceNow REST through Integration Hub, and custom scripted inputs.

Common Data Source Types

The appropriate source depends on the architecture.

For instance, if a third-party application exposes a REST API, creating a JDBC connection just to retrieve the same data would add unnecessary infrastructure. Conversely, if the organization has a reporting database containing millions of records and controlled database access is available, JDBC may be more practical.

Real-World Data Source Use Cases

Use Case 1 – Employee Data from an HR Database

A company maintains employee information in an enterprise HR database.

Every night, ServiceNow needs:

• Employee ID

• First name

• Last name

• Email

• Department

• Manager

• Location

• Employment status

The integration can use a JDBC Data Source to retrieve the records.

The flow becomes:

HR Database
     ↓
JDBC Data Source
     ↓
Import Set Table
     ↓
Transform Map
     ↓
sys_user

A coalesce field such as Employee ID can be used to determine whether ServiceNow should update an existing user or create a new one.

Use Case 2 – CMDB Data from an External System

Suppose an organization has infrastructure information in another monitoring platform.

The requirement is to periodically bring server information into ServiceNow.

The source may contain:

hostname
ip_address
operating_system
environment
serial_number
status

A REST Data Source or Integration Hub Data Stream can retrieve the information.

The data can then be staged and transformed before reaching the appropriate CMDB structure.

In a CMDB implementation, however, simply inserting records into a target table is not always enough. Identification and reconciliation rules should be considered so that existing Configuration Items are not duplicated.

Use Case 3 – Daily Application Inventory File

A software team generates a daily Excel file containing application inventory.

Example:

The file can be configured as a File Data Source.

ServiceNow loads the file into an Import Set table, validates the information, and transforms it into a custom application table.

This approach is common during migrations when the source application does not expose a convenient API.

Data Source Architecture and Technical Flow

A typical implementation follows this architecture:

                 External Application
                         |
             +-----------+-----------+
             |           |           |
            File       JDBC        REST
             |           |           |
             +-----------+-----------+
                         |
                    Data Source
                         |
                    Import Set
                   Staging Table
                         |
                  Transform Map
                         |
              Transformation Logic
                         |
                  Target Table
                         |
                ServiceNow Records

The important point is that the data normally does not move directly from the Data Source into the final ServiceNow table.

The Import Set provides the staging layer.

This gives developers an opportunity to:

• Validate incoming records

• Normalize values

• Convert data formats

• Handle duplicates

• Apply field mappings

• Reject invalid records

• Monitor import results

ServiceNow specifically recommends avoiding extremely large Import Set loads because oversized imports can cause performance problems or delays.

Prerequisites Before Creating a Data Source

Before creating the configuration, confirm the following.

1. Source System Availability

For a database integration, confirm:

• Database hostname

• Port

• Database name

• Credentials

• Required driver

• Network connectivity

For REST:

• Endpoint URL

• Authentication method

• Required headers

• Request parameters

• Response structure

For SFTP:

• Server

• Port

• Directory

• Username

• Authentication method

• File naming convention

2. Target Table

Identify the destination table.

For example:

sys_user
cmdb_ci_server
incident
cmdb_ci
custom application table

Do not start with field mapping before understanding the target data model.

3. Unique Identifier

Identify the business key.

Examples:

Employee ID
Asset Serial Number
Application ID
Vendor ID
Customer Number

This becomes particularly important when configuring coalesce behavior.

4. Required Roles

ServiceNow’s current documentation indicates that creating certain Data Source configurations requires the import_admin role, while some Integration Hub Data Stream configurations require import_admin and action_designer.

Step-by-Step: Create a File Data Source

A file-based Data Source is one of the easiest ways to understand the complete Import Set architecture.

Step 1 – Navigate to Data Sources

Go to:

All → System Import Sets → Administration → Data Sources

Click New.

This is the current ServiceNow navigation documented for creating Data Sources.

Step 2 – Enter the Data Source Name

Example:

HR Employee Master

The name should describe the business purpose rather than simply saying:

Test Import

A production environment may eventually contain dozens or hundreds of Data Sources, so meaningful naming becomes important.

Step 3 – Define the Import Set Table

Example:

Import set table label:
HR Employee Import

Import set table name:
u_hr_employee_import

The staging table is where incoming data will initially reside.

Current ServiceNow documentation notes that the platform constructs a unique Import Set table name from the label and that Import Set columns are generated from imported data.

Step 4 – Select the Type

Select:

Type → File

Then configure the file format and retrieval method appropriate for the source.

Depending on the implementation, ServiceNow supports file retrieval mechanisms such as attachment, SFTP, FTP, HTTP, HTTPS, and SCP. ServiceNow currently recommends considering SFTP instead of FTP where encrypted transfer is required.

Step 5 – Configure the File

Suppose the organization receives:

employees_2026_09_25.csv

The expected columns might be:

employee_id
first_name
last_name
email
department
manager_id
status

Make sure the source file follows a consistent structure.

For CSV files, the first row is used as the header that defines the columns for the Import Set.

Step 6 – Test Load

Use the Data Source testing option to load a limited number of records.

The objective is not to process the entire production file immediately.

First verify:

• File can be retrieved

• Columns are recognized

• Data appears correctly

• No encoding issues exist

• Dates are readable

• Null values behave correctly

ServiceNow provides a Test Load 20 Records capability for validating a Data Source and creating the Import Set table.

Step-by-Step: Create a REST Data Source

REST-based Data Sources are useful when the external system exposes an API.

Navigate to:

All → System Import Sets → Administration → Data Sources → New

Select:

Type → REST (IntegrationHub)

Current ServiceNow documentation describes this Data Source type as a mechanism for defining the data that an Import Set should obtain from a REST API.

Example conceptual configuration:

Name:
Employee REST API

Import Set Table:
Employee REST Import

Type:
REST (IntegrationHub)

Endpoint:
https://example-system/api/employees

The actual endpoint and authentication configuration depend on the external system.

Before moving into transformation, test the API independently.

Check:

• HTTP status

• Response format

• Authentication

• Pagination

• Required parameters

• Error response

• Number of records returned

A successful HTTP response does not necessarily mean a successful ServiceNow transformation.

For example:

{
  "employeeId": "E1001",
  "email": "user@example.com",
  "department": "Finance"
}

must eventually be mapped to the corresponding ServiceNow fields.

JDBC Data Source for Database Integration

JDBC is commonly used when ServiceNow must retrieve information directly from a database.

A typical architecture is:

Oracle / SQL Server / Other DB
             ↓
          JDBC
             ↓
       ServiceNow Data Source
             ↓
        Import Set Table
             ↓
        Transform Map

For example, suppose the source query returns:

SELECT
    employee_id,
    first_name,
    last_name,
    email,
    department_code
FROM employee_master
WHERE active_flag = 'Y';

The implementation team can retrieve only the records required for the ServiceNow process rather than importing the entire source table.

This is an important consultant-level optimization.

If the source database contains 2 million records but ServiceNow only needs active employees changed since the previous execution, the integration should use an appropriate incremental strategy rather than repeatedly loading all 2 million records.

Some JDBC configurations may require a ServiceNow MID Server depending on the network architecture.

Transform Map: The Next Critical Layer

Creating the Data Source is only the beginning.

The next stage is the Transform Map.

For example:

A Transform Map determines how fields from the staging table are mapped into the target ServiceNow table.

Coalesce

Coalesce is particularly important.

Suppose the source contains:

employee_id = E1001

and ServiceNow already contains employee E1001.

If Employee ID is configured as the appropriate coalesce field, the transformation can identify the existing record and update it instead of creating another record.

Conceptually:

Match found → UPDATE
No match → INSERT

Without a suitable business key, repeated integrations can create duplicate records.

Testing the Data Source

A consultant should never move directly from configuration to production.

Use a controlled test sequence.

Test 1 – One Valid Record

Input:

E1001 | Ravi | Kumar | ravi@example.com | FIN

Expected result:

One ServiceNow record created or updated

Test 2 – Existing Record

Send the same Employee ID again with a changed department.

Expected result:

Existing record updated

not:

Second record created

Test 3 – Missing Required Field

Send:

E1002 | Priya | | priya@example.com

Expected behavior should be defined by the transformation design.

The record might be rejected, skipped, or handled through transformation logic depending on requirements.

Test 4 – Invalid Reference

Suppose:

manager_id = M99999

does not exist in ServiceNow.

Verify how the reference field is handled.

Test 5 – Large File

After functional testing, test realistic data volumes.

Do not use a massive production file as the first performance test. ServiceNow explicitly cautions against extremely large Import Set chunks because they can cause delays or outages.

Common Data Source Problems and Troubleshooting

1. Data Source Loads Successfully but No Target Records Are Created

Check:

• Import Set table

• Transform Map

• Active status

• Field mappings

• Transform errors

• Coalesce configuration

A successful source extraction does not guarantee successful transformation.

2. Duplicate Records Are Created

Usually investigate the business key first.

Ask:

What uniquely identifies this record in the source system?

For employees, it might be Employee ID.

For hardware, it could be Serial Number.

For applications, it could be Application ID.

Configure the transformation accordingly.

3. Date Values Are Incorrect

Typical source value:

25/09/2026

while ServiceNow expects another format.

The transformation must explicitly account for the source date format.

Do not assume that because a date looks correct in Excel, it will automatically be interpreted correctly by ServiceNow.

4. Reference Fields Do Not Populate

Suppose the source contains:

department = FIN

but the ServiceNow Department field expects a reference record.

The transformation needs to resolve the incoming business value to the correct referenced record.

This is a common issue in employee and CMDB integrations.

5. REST Data Source Returns Unexpected Data

Check:

• API response structure

• Authentication

• Pagination

• HTTP status

• JSON hierarchy

• Required headers

• Response transformation

A REST endpoint returning HTTP 200 does not automatically mean the expected records were extracted.

6. JDBC Connection Fails

Check:

• Hostname

• Port

• Credentials

• Database availability

• Driver configuration

• Firewall

• MID Server connectivity where applicable

Network connectivity should be validated before debugging Transform Maps.

Data Source Best Practices

Use Meaningful Naming

Prefer:

HR_Employee_Master_JDBC
CMDB_Server_REST
Application_Inventory_SFTP

instead of:

Test1
Import2
DataSourceNew

Design for Incremental Loads

Do not repeatedly extract the entire source dataset when only changed records are required.

Consider:

last_updated_date
last_modified_timestamp
change_sequence
status

depending on what the source system supports.

Keep Staging and Target Logic Separate

Do not place all transformation logic into the Data Source.

Use the appropriate layer:

Data Source → Retrieve
Import Set → Stage
Transform Map → Transform
Target Table → Persist

This makes troubleshooting much easier.

Validate Before Production

Test:

1. Valid record

2. Duplicate record

3. Missing required value

4. Invalid reference

5. Invalid date

6. Large volume

7. Source unavailable

8. Authentication failure

Monitor Import Performance

Import Set cleanup is important because staging data can accumulate.

ServiceNow’s current Import Set documentation describes a scheduled cleanup mechanism that removes older Import Set data; the default documented behavior removes Import Sets older than seven days.

Avoid Manually Modifying Generated Import Set Columns

Import Set table columns are generated based on imported data. ServiceNow cautions against manually adding columns because doing so can interfere with scheduled cleanup and create orphaned records.

Use Secure Transport

For file-based integrations, prefer encrypted transfer mechanisms such as SFTP where appropriate.

Avoid sending credentials or sensitive employee data through insecure channels.

Data Source in ServiceNow: Practical Implementation Checklist

Before handing an integration to production, confirm:

This checklist is simple, but it prevents many production integration issues.

Frequently Asked Questions

1. What is a Data Source in ServiceNow?

A Data Source is a configuration record that defines where ServiceNow obtains data for an Import Set. Depending on the integration, the source can be a file, database, LDAP directory, REST endpoint, Data Stream, or another supported mechanism.

2. What is the difference between a Data Source and an Import Set?

A Data Source defines where the data comes from, while the Import Set provides the staging area where the retrieved records are temporarily stored before transformation.

For example:

Data Source = HR database
Import Set = Temporary employee staging table
Transform Map = Rules for moving employee data
Target = sys_user

3. Can ServiceNow Data Sources be used for scheduled integrations?

Yes. Data import processes can be scheduled so that external information is periodically retrieved and processed. ServiceNow provides administration capabilities for running and scheduling imports through the Import Set framework.

Expert Consultant Tips

A Data Source looks like a simple configuration record, but in an enterprise implementation it is part of a larger data architecture.

When designing one, do not ask only:

“How can I import this file?”

Instead ask:

• What is the source system of record?

• What identifies a unique record?

• Is this a full or incremental load?

• How should duplicates be handled?

• What happens when a reference does not exist?

• How will failed records be identified?

• What is the expected daily volume?

• How frequently should the data be synchronized?

• What happens when the source system is unavailable?

• Who owns the data quality?

For example, an employee synchronization may appear to be a simple HR → ServiceNow integration. In production, however, it can involve identity matching, manager relationships, department references, inactive users, duplicate prevention, incremental loads, error handling, security, and monitoring.

That is why the Data Source should be designed as part of the complete Import Set architecture rather than treated as an isolated configuration.

Summary

A Data Source in ServiceNow defines the origin and retrieval mechanism for external data used by the Import Set framework. The data is typically staged in an Import Set table and then transformed into a ServiceNow target table using a Transform Map or an appropriate transformation mechanism.

The most important architecture to remember is:

External System
      ↓
Data Source
      ↓
Import Set Table
      ↓
Transform Map
      ↓
Target Table

File, JDBC, REST, LDAP, OIDC, Data Stream, and scripted approaches can support different integration requirements. The correct choice depends on the source architecture, security requirements, data volume, connectivity, and processing model.

For enterprise projects, the real value comes from designing the entire data flow correctly: selecting a reliable business key, controlling duplicates, validating references, supporting incremental loads, testing realistic volumes, securing the connection, and monitoring failures.

For additional Oracle Cloud reference material where ServiceNow is being integrated with Oracle Fusion applications, see the Oracle Cloud Applications documentation and the Oracle Fusion Cloud Time and Labor 26A documentation. The Time and Labor documentation is useful when designing integrations involving employee time data and downstream payroll or project processes.