ServiceNow: Inventory Discovery & Exports

The ServiceNow integration does three things, and one account can do any combination of them:

• Inventory discovery reads the records from a table in your instance (typically a CMDB table) and brings them into Connect's Inventory, one item per record with the IPs from a field you name.
• Change request export pushes a Connect change request that has passed a Boundary evaluation into an import staging table in your instance, one row per rule.
• Decommissioned asset export pushes the assets a Decommission action matches into a second staging table, one row per asset.

Both exports use ServiceNow's Import Set pattern: Connect creates the staging tables and fills them, and a transform map that you create moves each row into whatever target table fits your instance. That keeps the mapping in your hands, so Connect never writes into change_request or cmdb_ci directly.

Before you start

Prerequisite	Why it's needed	Where to check in ServiceNow
Your instance name, the subdomain of your instance URL (acme for https://acme.service-now.com)	Every API call goes to it	Your browser's address bar
A service account with read access to the table you're importing	Discovery reads it through the Table API	The table's access controls
For export, the same account also needs the built-in import_set_loader role, or equivalent access to sys_db_object, sys_dictionary, sys_import_set_row, the Import Set API, and the Batch API	Provisioning creates the staging tables; each export loads rows into them	User Administration > Users, the account's Roles
For discovery, the table and the field that holds IP addresses (for example cmdb_ci_server and ip_address)	Discovery only reads that one table, and only that field becomes IPs	System Definition > Tables

Set up a ServiceNow account

1. In Connect, go to Settings > Accounts and add a new account.
2. Cloud Provider: ServiceNow. Give it an Account ID (any identifier that's unique among your accounts; the instance name works well), a name, and a project.
3. Save. You land on the Provision page.
   • Under Configure for, leave Import checked for inventory discovery and Export checked for the two exports. Uncheck whichever you don't want.
   • Under Credentials, fill in the Instance Name, Username, and Password. The password must be re-typed on every save of this page; see Passwords and tokens are never shown back to you.
   • Under Import Settings (shown when Import is checked):
     • Table Name: the table to read, for example cmdb_ci_server.
     • IP Field Name: the field whose value becomes the item's IP addresses, for example ip_address.
     • Tag Field Names: optional, comma-separated. Each named field becomes a tag on the item, with the field name as the key.
4. Save. If Import is enabled, the first discovery starts on its own. If Export is enabled, Connect creates the two staging tables in your instance right away (see Exports).

Inventory discovery

Each record becomes one inventory item of type Table Record, sourced from ServiceNow:

Record field	Where it lands
sys_class_name and sys_id	The item's name, as <class>/<sys_id>
The field named in IP Field Name	The item's IP addresses (see below)
Each field named in Tag Field Names	A tag, keyed by the field name
last_discovered	The item's last-seen time, which Decommission uses to spot idle assets
mac_address	The item's MAC address

The IP field can hold a single address, a CIDR, a comma-separated list, or a range written as 10.0.0.1-10.0.0.20 (.. and ... also work). Ranges are expanded to the CIDRs that cover them. A value that can't be parsed is kept as-is.

Records are matched between runs by sys_id. A record that no longer exists in the table is removed on the next run.

Verify it landed

What to check	Where to look
The account has no errors	Settings > Accounts: no warning icon on the ServiceNow account, and its Provision page shows no Resource Errors
The item count	Integrations in the main navigation: the ServiceNow row is Active and its Items count roughly matches the row count of the table in ServiceNow
The items themselves	Inventory > Resources, filtered by Vendor > ServiceNow. Open one: its IPs should match the record's IP field

Exports

When you save the Provision page with Export enabled, Connect creates two staging tables in your instance, each extending ServiceNow's sys_import_set_row:

Staging table	Label in ServiceNow	Filled by
u_connect_change_requests_staging	Connect Change Requests	Change request export
u_connect_decommissioned_assets_staging	Connect Decommissioned Assets	Decommissioned asset export

If a table already exists it's reused, never overwritten. The tables are created the moment you save, so you can build the transform maps before the first export runs.

Create the transform maps

This is the part you do in ServiceNow, once per export you use. Go to System Import Sets > Administration > Transform Maps and create:

Export	Transform map Name (must match exactly)	Source table	Typical Target table
Change requests	Change Request Transformation Map	u_connect_change_requests_staging	change_request, or any table you choose
Decommissioned assets	Decommissioned Asset Transformation Map	u_connect_decommissioned_assets_staging	cmdb_ci, or any table you choose

Then add Field Maps from the staging columns (all prefixed u_) to your target's fields. Everything ServiceNow's transform maps support is available: coalesce keys to update rather than duplicate (use u_id + u_rule_id for change requests, u_workflow_id + u_id for decommissioned assets), and transform scripts to parse the JSON fields or look up users and CIs.

ServiceNow's guide: Create a transform map.

Change request export

Export is driven by Boundaries. When a change request is evaluated against a Boundary and the result is Pass or Review, Connect exports it to every target on that Boundary. Fail and error results export nothing.

1. Open the Boundary (or create one) under Boundaries.
2. In Target(s), select your ServiceNow account. It appears as ServiceNow (your account name). Only accounts with Export enabled are listed.
3. Save the Boundary.

Each rule in the change request becomes one staging row. The change request's fields (u_id, u_name, u_created_at, u_created_by, u_updated_at, u_updated_by, u_score) repeat on every row; the rule's fields (u_rule_id, u_action, u_services, u_justification, u_comment, u_owner, u_expiration, u_raw) are per row. u_services is the rule's services as written, one JSON object per service: type, plus portStart and portEnd for TCP and UDP, icmpType and icmpCode for ICMP, or protocol for a custom protocol (see the Schema). u_raw is the rule exactly as it was written, including its own sources and destinations. Date fields are UTC in ServiceNow's YYYY-MM-DD HH:MM:SS form.

u_sources and u_destinations belong to the whole change request, not the row. They are JSON arrays of the resolved IP addresses and CIDRs, with Groups and inventory items expanded, for every rule in the request combined, and the same two arrays repeat on each row. With one rule they are exact. With several rules that reference different Groups or inventory items, each row lists more addresses than its own rule allows: map a rule's own sources and destinations from u_raw, and treat u_sources and u_destinations as the request's overall scope.

To verify, submit a change request that passes the Boundary, then look at u_connect_change_requests_staging in ServiceNow for the rows, and at your target table for the transformed records. Every evaluation exports again, so re-evaluating a change request adds rows unless your transform map coalesces on u_id and u_rule_id.

Decommissioned asset export

Export is driven by Decommission actions.

1. Under Decommission > Actions, create or edit an action.
2. In Destination, select your ServiceNow account. It appears as ServiceNow (your account name).
3. Save. Every asset the action matches from then on is exported.

Each matched asset becomes one staging row: the match context (u_workflow_id, u_hit_count, u_last_hit_at, u_last_seen_at, and their sources) plus the asset's own fields (u_name, u_hostname, u_ips as a JSON array, u_mac_address, u_vendor, u_type, u_type_name, u_region, u_cloud_account_id, u_cloud_account_name, u_cloud_account_env, u_updated_at, and more).

To verify, open Decommission > History in Connect. Each export shows Pending, Success, or Error; hover an Error tag to read the message. On the ServiceNow side, check u_connect_decommissioned_assets_staging for the rows and your target table for the transformed records.

Details and edge cases

Provisioning succeeds even if the staging tables couldn't be created. Table creation runs when you save, but a failure there (usually the service account lacking sys_db_object access) doesn't block the save. The symptom appears later, when the first export fails against a missing table. After provisioning, confirm both tables exist under System Definition > Tables before building the transform maps.

Exports go to the staging table whether or not a transform map exists. Without one, rows accumulate in the staging table and nothing reaches your target table. That's the first thing to check when the staging table fills but your target stays empty.

One account serves both exports. Each export has its own staging table and transform map.

Nothing in Connect records a change request export. The change request page shows the Boundary result, not whether the rows reached ServiceNow. Decommission exports, by contrast, are tracked under Decommission > History.

For common issues, see Troubleshooting.

ServiceNow documentation

• Create a transform map: the one piece of setup done in ServiceNow, including coalescing to update existing records instead of duplicating them
• In the ServiceNow REST API reference for your release: the Table API (what inventory discovery reads), the Import Set API (how exports load the staging tables), and the Batch API (how rows are sent)