The Yeti Data Loader: Bulk-Loading ServiceNow Data Without the SQL Pain

Why Bulk Loads Hurt

Bulk-loading data into ServiceNow has always been a chore. The standard path is to upload a CSV or XLS as an Import Set, build a Transform Map, configure field mappings, write coalesce and onBefore/onAfter scripts, run the transform, and then chase down the error rows in sys_import_set_row. For a one-shot load that is fine. For a recurring data feed of CIs, users, or vendor records it becomes its own small project.

Worse, when the data is messy, which it always is, the developer ends up writing Transform Map scripts that look more like ETL than configuration. Coalesce logic for a CMDB load can run to dozens of lines. Reference field lookups break silently when the upstream name does not match. And nobody wants to maintain a hand-rolled REST client just to keep a list of cost centres in sync.

The Yeti Data Loader is built to remove that work. It appears in the Yeti web app sidebar alongside Projects, Templates, ServiceNow, Yeti Drive, Audit & MSP, Billing, API Keys, and Team, so it is one click from wherever you are in Yeti.

What the Data Loader Actually Does

The Data Loader takes a structured file and a target ServiceNow table, then orchestrates the load end to end. It handles inference of column types, suggests a coalesce strategy, resolves reference fields against the live instance, dry-runs the load to show you what will change, and only commits once you approve.

In practice that means a workflow like:

1. Pick a target table, for example cmdb_ci_server.
2. Upload a CSV, XLSX, or JSON file from your machine or from Yeti Drive (each user has 250 MB of secure storage).
3. Review the auto-suggested column mapping. The loader uses the connected instance schema to match source columns to fields, so serial_number, Serial No, and serial all resolve to serial_number without you doing anything.
4. Set the coalesce key. The loader recommends one based on uniqueness analysis of the source data.
5. Click Preview. You get a row-by-row diff: how many records will be inserted, how many updated, and which rows will be skipped because of missing references.
6. Approve and run. The loader streams records into the instance through the standard Import Set + Transform Map flow, then reports back row counts, error rows, and the URL of the generated sys_import_set.

Because it runs through Import Sets and Transform Maps, everything is auditable in ServiceNow exactly as if you had built the load by hand. The difference is you did not have to.

A Real Bulk Load: Servers Into the CMDB

Suppose you have a CSV exported from your VMware vCenter and you want every record in cmdb_ci_server. The file looks something like this:

Hostname,Serial,CPU Cores,RAM (GB),OS,Owner Email
sn-app-01.acme.local,VMW-001,8,32,Ubuntu 22.04,[email protected]
sn-app-02.acme.local,VMW-002,16,64,Ubuntu 22.04,[email protected]
sn-db-01.acme.local,VMW-101,32,256,RHEL 9,[email protected]

The Data Loader proposes this mapping after a single click:

Source              -> Target field           Coalesce
------              -- ------------           --------
Hostname            -> name                   yes (proposed)
Serial              -> serial_number          alternate key
CPU Cores           -> cpu_count              no
RAM (GB)            -> ram                    no (units: GB)
OS                  -> os                     no
Owner Email         -> owned_by               reference -> sys_user.email

Notice the Owner Email column. The loader detected that cmdb_ci_server.owned_by is a reference to sys_user and that the source data is an email address. It will resolve each email against sys_user.email live, and any rows that fail to resolve are surfaced before commit. You do not write a coalesce script. You confirm a mapping.

On Preview, you might see something like "1,438 inserts, 27 updates, 5 unresolved owners, 0 type errors." The five unresolved rows include the source data so you can either create the missing users first or skip those rows. The whole loop, from upload to commit, is typically minutes, not hours.

Repeatable Loads and What Yeti AI Chat Adds

The Data Loader saves load definitions, so the next time the same shape of file appears you do not start from scratch. Save a definition once and the mapping, coalesce keys, and reference resolution rules are reused on every subsequent run.

For more complex transformations, where source data needs cleaning or enrichment before it lands, you can open the file in Yeti AI Chat and prompt your way through the cleanup. The chat sits side by side with the Data Loader in the sidebar. A typical flow is:

Yeti AI Chat returns the cleaned file, which you can then send straight to the Data Loader. Switch between the four AI modes (General, Guru, Thinking, Fast) and the four hats (BA, Architect, Security, Sr Dev) depending on whether you need quick cleanup or a deeper review. Detail on the modes lives on the Yeti AI Chat page.

When the load is part of a larger build, the Yeti Build Agent can take the load definition as part of a scoped app brief and emit it as Fluent SDK source, which is covered in detail on the Yeti Build Agent page.

Where It Fits in Your ServiceNow Stack

The Data Loader is part of Yeti AI Chat, available on every tier including Standard. Connection to your ServiceNow instance uses the same secure OAuth flow that the rest of Yeti relies on, which is documented on the ServiceNow integration page. Supported releases are Zurich onwards.

For MSPs running data loads across many tenants, the loader plays well with the 8 MSP Agents (6 scheduled, 2 on-demand) covered on the MSP Agents page. Scheduled loads can be initiated from agent runs, and the resulting Import Set IDs are recorded against the tenant.

Related Reading