ServiceNow -- Push to CMDB

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

xAssets supports two ServiceNow integrations -- a push integration (this page), which uploads asset data into ServiceNow as Configuration Items (CIs), and a pull integration, 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 push integration takes computer assets from xAssets and creates or updates matching CI records in the ServiceNow CMDB. It provides:

• CI master data -- 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, chassis type
• Software Installed tab -- every installed software title is created in the ServiceNow software catalogue (cmdb_ci_spkg) and linked to the CI through cmdb_software_instance records
• Network Adapters tab -- one record per MAC address with the associated IP address
• File Systems tab -- one record per logical drive with size and free space in bytes
• Correct CI class selection -- xAssets computer types are mapped to the appropriate ServiceNow subclass automatically (Windows servers go into cmdb_ci_win_server, laptops into cmdb_ci_pc_hardware, etc.)
• Reverse data normalisation -- xAssets uses its own recognition engine in reverse to map ServiceNow's manufacturer and model names to the xAssets canonical names, so a Dell asset in xAssets correctly links to ServiceNow's "Dell Inc." record rather than creating a duplicate
• Scoped reference fetch -- the integration only retrieves models linked to the manufacturers that are actually being pushed, so it scales to customer instances with thousands of models in the ServiceNow CMDB

The integration is designed to push the entire ServiceNow CMDB-quality dataset that xAssets has already cleaned, recognised and reconciled. ServiceNow does not provide its own normalisation framework, so customers benefit from xAssets pre-processing the data before it lands in their CMDB.

Limitations

The following data is in xAssets but is not currently mapped into ServiceNow:

• Memory Modules tab -- ServiceNow's cmdb_ci_memory_module table does not have a direct parent reference field, so the records are created but the related list does not display them. Resolution requires the cmdb_rel_ci relationship table; this is on the roadmap.
• Storage HBAs, Storage Devices, Serial Numbers, CI IPs, DNS Names, Running Processes, TCP Connections tabs -- not yet implemented.
• assigned_to (custodian → sys_user), company (CompanyDesc → core_company), location (LocationName → cmn_location), department (DepartmentName → cmn_department) -- the names are sent but ServiceNow only resolves them if matching sys_user / core_company / cmn_location / cmn_department records already exist with the exact same display value. If they do not, the field is stored as raw text and shows blank in the ServiceNow UI.
• BIOS details, OS service pack, OS architecture, hyper-threading information -- collected by xAssets but not part of the standard cmdb_ci_computer schema.

Reverse Recognition Pattern

ServiceNow has no data normalisation. Without a reconciliation step, an integration would either create thousands of duplicate companies and models or silently drop fields where the names do not match exactly.

The xAssets push integration uses its own recognition engine in reverse:

1. Fetch ServiceNow's reference data (e.g. all of core_company, then only the cmdb_model records linked to manufacturers we use)
2. Run the xAssets recognition rules against ServiceNow's names to map each one to the xAssets canonical name (for example, "Dell Inc.", "Dell Computer Corp" and "Dell Technologies" all become "Dell")
3. Build a truth table that maps "xAssets canonical name" to "ServiceNow record sys_id"
4. When pushing each CI, join through this truth table to send ServiceNow the correct sys_id for manufacturer and model

This is a strong differentiator versus other CMDB integrations -- xAssets' 30+ years of recognition rules cover thousands of variations that ServiceNow's content library does not.

Prerequisites

• A ServiceNow instance (developer instance, sub-production, or production)
• A ServiceNow user account with permission to create and update CMDB records, ideally a dedicated integration user with the rest_api_explorer and itil 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) with a strong password
3. Assign at minimum these roles:
   • rest_api_explorer -- required to call the Table API
   • itil -- required to read and write CMDB records
4. For a developer instance you can use the admin account, but a dedicated 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.

Step 4: Run the Integration

1. Navigate to Discover > Integrations
2. Select ServiceNow Integration -- Push to CMDB 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:
   • "Connecting to ServiceNow" -- authentication and connectivity test
   • "Staging assets for ServiceNow push" -- selecting the assets to push
   • "Creating reference data in ServiceNow" -- creating any missing manufacturers, models, OS choices and the xAssets discovery source
   • "Building xAssets to ServiceNow reference mapping via recognition" -- pulling SN reference data and running reverse recognition
   • "Pushing N assets to ServiceNow CMDB" -- creating CI records (one API call per asset)
   • "Pushing detail records (NICs, disks)" -- populating Network Adapters and File Systems
   • "Pushing software catalog and install records" -- creating cmdb_ci_spkg and cmdb_software_instance records
   • "ServiceNow Push completed. Created=X Updated=Y Failed=Z"

Step 5: Verify the Results

After the integration completes:

1. In ServiceNow, navigate to All > Configuration > Base Items > Computers
2. Open one of the pushed CIs and verify:
   • Header fields -- name, serial number, manufacturer (resolves to a company record), model (resolves to a cmdb_model record)
   • Configuration tab -- OS, OS version, RAM, CPU type, CPU speed, CPU count, CPU core count, disk space, DNS domain, IP address, chassis type, virtual flag
   • Software Installed tab -- software titles linked through cmdb_software_instance
   • Network Adapters tab -- MAC and IP address records
   • File Systems tab -- logical drive records with size in GB and free space in GB
   • Discovery source -- shows xAssets

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 the rest_api_explorer and itil roles
• 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)

CIs are created but manufacturer or model is blank

The reverse recognition step may not have found a matching ServiceNow record. The push will still create the CI, but the field is left empty so that the customer's own ServiceNow data is not corrupted with raw text.

To fix:

1. In ServiceNow, manually create the missing core_company or cmdb_model record with the correct name
2. Re-run the integration -- the next reverse-recognition pass will pick it up

If the issue affects many records, the xAssets recognition rules can be extended to cover the customer's specific ServiceNow naming conventions.

Software Installed tab is empty even though cmdb_ci_spkg records exist

The Software Installed related list reads from cmdb_software_instance (a link table joining a CI to a software package). Verify that the install records are being created -- the integration runs the catalog POSTs first and the install POSTs second. A push of 200+ unique software titles can take several minutes.

Memory Modules tab is empty

This is a known limitation -- the records are created but ServiceNow's standard related list mechanism does not display them. See the Limitations section above.

Special Options

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

Scheduling

To run the ServiceNow push integration on a schedule, configure a batch job schedule for the ServiceNow Integration -- Push to CMDB transform. A daily or weekly sync is typical.

The integration is upsert-friendly -- subsequent runs find existing CIs by name and update them in place rather than creating duplicates.

Related Articles

• ServiceNow -- Pull from CMDB -- the reverse direction, importing ServiceNow CIs into xAssets
• Tanium -- another endpoint inventory integration that can be combined with the ServiceNow push to give ServiceNow a richer dataset
• Microsoft Intune