QA testing of ServiceNow Data Sources, Import Sets and Transform Maps

Data Sources in ServiceNow are used to create an intermediate import set. Import set table data is then mapped to a production table via a Transform Map. Import set data can be inspected and manipulated before that mapping runs, which is exactly what makes it useful for testing.

Data for a Data Source can come from four places: a recognized file format (CSV, Excel, XML, JSON), an external database via JDBC, an LDAP server, or an HTTP-based source — which covers REST and SOAP web services.

Why This Trips Up QA Testers

Since the import set table acts as a staging area for records pulled in from a Data Source, that staged data can be manipulated for testing before it gets pushed into the production table through the Transform Map's field mappings. To a ServiceNow developer, this is familiar territory. QA testers, especially those newer to the platform, often find it harder than it should be — usually for one of three reasons:

• Import sets can have thousands of rows, and running the full set can take a long time just to get to the scenario they actually want to test.
• Testing multiple scenarios means running the Data Source multiple times, which adds up to a lot of hours if every run processes the full dataset. Developers tend to know shortcuts for running and testing just the rows that matter; testers often don't.
• Some of the steps require elevated permissions — testers without those roles end up relying on a developer or admin to run the steps for them rather than doing it independently.

The steps below are aimed at closing that gap, so QA testers can run these tests independently rather than routing every test cycle through a developer.

Step-by-Step: Isolating Rows for Testing

1. Note down details — reports or screenshots — of the table or form involved in the Data Source testing, so you have a baseline to compare against after the transform runs.
2. Open the Data Source record and select Load All Records (in Related Links) to run it and load all data rows.
3. If the Data Source involves a large amount of data, this takes some time to process. Once State shows Complete and Completion Code shows Success, go to Import Sets and note the Import Set number.
4. Identify the specific rows from the Import Set you actually need for your test scenario.
5. Once you know which rows you need, delete the rest using Scripts – Background.

Note on permissions: running Background Scripts requires at minimum the admin role on most instances. Some organizations additionally require security_admin elevation as an extra safeguard for scripts that delete data, even staging data — check your instance's specific configuration, since this can vary by organization rather than being a fixed platform requirement.

For example, say the Data Source name is "Test Import Assets", the Import Set table name is "u_test_import_assets", and the Import Set number is "ISET1234567":

var gr = new GlideRecord('u_test_import_assets'); //Import Set table name
gr.addQuery('sys_import_set.number', 'ISET0017093'); //Import Set number
gr.addQuery('sys_import_state', 'pending');
//Delete Import Set table rows except row numbers 944, 5612, 8881
gr.addQuery('sys_import_row', 'NOT IN', '944,5612,8881');
gr.deleteMultiple();

1. With unwanted rows deleted from the Import Set table, run the Transform Map for that Import Set to complete the data update in the production table — now against only the rows you actually want to test.
2. Import set row data can be changed or manipulated directly to perform positive or negative testing, depending on the scenario.
3. With this approach, testing runs against a small, deliberate set of rows, so QA testers can run multiple test cycles quickly instead of waiting on a full-dataset run every time.

One More Thing Worth Knowing

Import set staging tables aren't meant to hold data indefinitely — ServiceNow runs a scheduled cleanup job (commonly referred to as the Import Set Deleter) that removes import set records older than 7 days by default, along with their associated staging rows and transform history. This is generally invisible during normal testing, but it's worth knowing if you're revisiting an import set from a previous test cycle and can't find it anymore — it may simply have aged out rather than something being wrong with your test setup.