ServiceNow -- Pull from CMDB

xAssets includes a built-in integration to pull asset data from the ServiceNow CMDB into xAssets. This page explains what the integration provides, its limitations, and how to set it up.

xAssets supports two ServiceNow integrations -- a push integration, which uploads xAssets data into ServiceNow as Configuration Items (CIs), and a pull integration (this page), which imports ServiceNow CIs into xAssets. Most customers run only one of the two, but they can be used together.

What the Integration Provides

The pull integration reads CI records from the ServiceNow CMDB and creates or updates matching asset records in xAssets. It uses the same Discovery Load pipeline that all other xAssets discovery integrations use (Tanium, Intune, JAMF, etc.), so the data goes through the full xAssets recognition, deduplication, and reconciliation engine before it lands in the Asset table.

The integration provides:

• Asset master data -- computer name, serial number, manufacturer, model, operating system, OS version, CPU type, CPU speed and core counts, RAM, disk space, primary IP address, MAC address, DNS domain, virtual flag, install status
• Software inventory -- every cmdb_software_instance record from ServiceNow is imported and pushed through the xAssets software recognition engine, so titles are normalised and rolled up against the xAssets software catalogue
• Network addresses -- IP addresses and MAC addresses per device
• Device classification -- the ServiceNow sys_class_name (e.g. cmdb_ci_win_server, cmdb_ci_pc_hardware) and virtual flag are mapped to the xAssets ComputerType
• Source tagging -- imported assets are tagged with Source = SERVICENOW so they are easy to identify in the Asset List

The integration pulls data from cmdb_ci_computer and all of its inheritance subclasses (Windows servers, Linux servers, PCs, virtual machines, etc.).

xAssets Recognition Improves ServiceNow Data Quality

ServiceNow has no data normalisation engine. The pull integration takes ServiceNow's raw data and runs it through the xAssets recognition rules, which:

• Normalise manufacturer names (Dell Inc., Dell Computer Corp, Dell Technologies all become Dell)
• Normalise model names (strip manufacturer prefix, expand abbreviations, standardise version suffixes)
• Recognise installed software titles against the xAssets catalogue (which has 30+ years of recognition rules)
• Deduplicate against existing xAssets assets by serial number or computer name

This is a strong differentiator -- customers who have struggled with messy ServiceNow data can use xAssets as a normalisation layer.

Limitations

• BIOS details, OS service pack, OS architecture, hyper-threading information, memory module details, Device Manager entries, Windows Updates, Windows Services -- not in the standard ServiceNow CMDB schema, so not pulled.
• Memory Modules, Storage HBAs, Storage Devices, CPUs, Serial Numbers and DNS Names related lists in ServiceNow -- not currently mapped (the master CI fields cover the typical use cases).
• The pull uses ServiceNow's sysparm_display_value=true query option to get reference fields (manufacturer, model) as plain names. As a side effect, scalar fields (RAM, CPU speed, disk space) come back as formatted strings (e.g. "16 GB", "2.4 GHz") which the integration converts back to numbers using SQL Server-specific functions. This will need to be reworked when xAssets is ported to MariaDB.

Prerequisites

• A ServiceNow instance with populated CMDB data
• A ServiceNow user account with read access to the CMDB tables, ideally a dedicated integration user with the rest_api_explorer and cmdb_read (or similar) roles
• Access to xAssets with permission to create credential packs
• The xAssets Batch Service must be running (the integration runs as a batch job)

Setup

Step 1: Identify Your ServiceNow Instance

Determine the URL of your ServiceNow instance. Examples:

You will need the domain part only (e.g. dev123456.service-now.com) without https:// and without a trailing slash.

Step 2: Create or Identify an Integration User in ServiceNow

For a production deployment, create a dedicated user account in ServiceNow:

1. In ServiceNow, navigate to User Administration > Users
2. Create a new user (e.g. integration.xassets.read) with a strong password
3. Assign at minimum the roles needed to read the CMDB (your ServiceNow administrator can confirm the exact role set; itil is sufficient on most instances)
4. For a developer instance you can use the admin account, but a dedicated read-only integration user is recommended for production.

Step 3: Create a Credential Pack in xAssets

1. Navigate to Discover > Prepare > Credentials
2. Click New
3. Configure the credential pack as follows:

4. Click OK to save the credential pack

Note: The Pack Name must be exactly ServiceNow -- the integration scripts read the credentials from this named pack. The same credential pack is used for both the push and pull integrations.

Step 4: Run the Integration

1. Navigate to Discover > Integrations
2. Select ServiceNow Integration by clicking its row
3. Click Queue at the top of the screen to add the integration to the batch job queue
4. The integration runs as a batch job. Monitor progress in the batch job status area at the top right of the screen. Status messages will show:
   • "Getting data from ServiceNow" -- fetching CI records (paged in batches of 100)
   • "Getting software install records from ServiceNow" -- fetching cmdb_software_instance records (paged)
   • "Transferring ServiceNow data to holding area" -- mapping into the NetworkDiscovery staging tables
   • "Loading ServiceNow holding area into assets" -- running the standard Discovery Load pipeline (validation, recognition, matching, software recognition, asset creation/update)
   • "ServiceNow Synchronise Completed. X asset records loaded."

Step 5: Verify the Results

After the integration completes:

1. Open the Asset List and filter by Source = SERVICENOW to see imported assets
2. Open an individual asset to verify:
   • Hardware details (manufacturer, model, serial number, memory, disk sizes)
   • Software titles appear on the Software tab and are recognised by the software catalogue
   • Network addresses and MAC addresses appear on the Network tab
   • Computer type matches the ServiceNow CI subclass

Troubleshooting

Authentication failure

Verify that:

• The Domain Name in the credential pack does not include https://
• The integration user account is not locked out and the password is correct
• The user has read access to cmdb_ci_computer and cmdb_software_instance
• The ServiceNow instance is awake (developer instances hibernate after about two hours of inactivity and take a few minutes to wake when the first request arrives)

Numeric conversion errors during the holding-area load

The pull uses sysparm_display_value=true so RAM and disk sizes come back as formatted strings like "16 GB" or "1024 MB". The integration parses these with TRY_CONVERT(float, ...) and unit conversion CASE statements. If a customer's ServiceNow instance returns an unexpected unit suffix, the conversion fails silently and the field is left null.

To diagnose, query the raw staging table after a run:

SELECT TOP 10 ComputerName, ram, disk_space FROM x7temp.dbo.servicenow

If the raw values look unusual, the SQL in transform 200 (Synchronise with ServiceNow 200 - ServiceNow to Holding Area) can be adjusted.

Missing assets

ServiceNow's cmdb_ci_computer table only includes records in subclasses that inherit from it. If the customer keeps assets in a custom CI class that does not inherit from cmdb_ci_computer, those assets will not be pulled. The integration can be modified to query the parent cmdb_ci_hardware table or a specific custom class instead.

Software titles missing or unrecognised

The pull imports raw software install records and pushes them through the xAssets software recognition engine. If a title is not recognised, it will appear in the asset's Software tab tagged as unrecognised. Add a recognition rule via Asset Management > Software > Software Recognition to teach xAssets the new title.

Special Options

The following Special Options can be configured in Admin > Special Options to customise the integration behaviour:

Scheduling

To run the ServiceNow pull integration on a schedule, configure a batch job schedule for the ServiceNow Integration transform. A daily sync is typical.

Each run is a full pull -- there is no incremental option in the standard ServiceNow Table API. For very large CMDBs (tens of thousands of CIs) consider scheduling outside business hours.

Related Articles

• ServiceNow -- Push to CMDB -- the reverse direction, exporting xAssets data into ServiceNow
• Tanium -- alternative endpoint inventory source that often produces cleaner data than a typical ServiceNow CMDB
• Microsoft Intune