Part 2 Full Quiz — Import Sets & Data Migration
18 questions (15 topic questions + 3 cross-topic integration) on Import Set lifecycle, Transform Maps, Data Sources, coalesce, and connections to IRE and Discovery. Select an answer to reveal the explanation.
What is the correct order of the three phases in Import Set processing?
C is correct. Import Set processing always follows: 1. Load — raw data is read from the source and written to the staging (import set) table; 2. Transform — Transform Map rules run against staging records, mapping and writing to the target production table; 3. Cleanup — staging records are optionally deleted or marked complete. Transforming before Loading (A) is impossible because the data doesn't exist yet.
What does the Import Set staging table represent?
B is correct. The Import Set staging table (named with u_import_ prefix by convention) is a temporary holding area. Raw data lands here exactly as imported — no transformation, no field mapping, no validation. Only after a Transform Map runs does the data flow to the target production table. The staging table is NOT the target (A), NOT a log (C), and NOT config storage (D).
[TRAP] Is this expected behavior?
B is correct. This is a common exam trap. Import Set staging records are NOT automatically deleted after transformation completes. They remain in the staging table and accumulate over time. Cleanup requires either a manual delete, a scheduled Import Set cleanup job, or configuring "Auto-cleanup" in Import Set configuration. Left unmanaged, staging tables grow indefinitely and can consume significant database space.
Which record type is the PRIMARY place to define field-level mapping from staging to target?
B is correct. The Transform Map (sys_transform_map) is where all field-to-field mapping is configured, along with Transform Scripts, coalesce settings, and target table definition. Each Transform Map contains multiple Field Maps that specify individual field mappings. sys_import_set is the run-level record, sys_import_set_row is the data, and sys_data_source is the connection config.
What does a Transform Map Field Map define?
B is correct. A Field Map defines one field-to-field mapping: source field (staging column) → target field (production column). It can also include a "Use source script" transform script to modify the value during mapping. One Field Map = one field pair. Coalesce (C) is configured per field map but is a setting, not the definition. Cleanup (D) and run conditions (A) are separate Transform Map settings.
What is the effect of "Run Business Rules" being checked?
B is correct. When "Run Business Rules" is enabled on a Transform Map, Business Rules on the target table execute during each record's transformation — just as they would on a normal form save. This allows validation, auto-population, and notification Business Rules to fire during imports. When unchecked (default), Business Rules are bypassed for faster bulk processing. Use with caution on large imports.
[TRAP] What specific mechanism achieves this upsert (update-or-insert) behavior?
B is correct. Coalesce is configured at the Field Map level by checking the "Coalesce" checkbox on the specific field that should be used as the match key (e.g., Employee ID). ServiceNow then looks up the target table for a record where that field matches the staging value — updating if found, creating if not. There is no separate "Upsert Mode" (D) or global "Check for Coalesce" checkbox on the Transform Map itself (A). Using a Business Rule (C) is possible but not the built-in mechanism.
answer = source.u_cost.toString();What does the answer variable represent in this context?
B is correct. In a Transform Script (field-level), the answer variable is the standard output variable — whatever you assign to answer becomes the value written to the mapped target field. The source object represents the current staging row (input). So this script reads the cost from staging, converts it to a string, and writes that string value to the target field. This pattern is foundational to all field-level transform scripting.
What does a Data Source record in ServiceNow define?
B is correct. A Data Source record defines the origin of the data: connection type (JDBC, FTP, HTTP, File), server address, credentials, file format (CSV, Excel, XML, JSON), and data structure. It answers "where does the data come from?" The transform logic (A) lives in the Transform Map. The schedule (C) is in a Scheduled Import. Coalesce/target (D) is in the Transform Map's Field Maps.
Where is the nightly schedule for an automatic Import Set run configured?
B is correct. A Scheduled Import record (found under System Import Sets → Administration → Scheduled Imports) links a Data Source to a schedule. It controls when the import loads data from the source AND optionally triggers Transform Map execution. The Transform Map itself has no schedule field (A). While a custom sys_trigger (C) is technically possible, it's not the standard mechanism. Data Source records (D) do not have a built-in auto-schedule field.
[TRAP] How does ServiceNow's Import Set framework handle nested JSON structures?
B is correct. Import Sets work with flat, tabular data. Each row in the staging table represents one flat record. Deeply nested JSON must be pre-flattened before loading (either via a pre-import script, an external ETL tool, or custom scripting in the Data Source processing). There is no "JSON Nesting" option (C) or JSONPath expressions (D) in standard Import Set configuration. Transform Scripts can handle simple dot-notation field extractions but not deep recursive nesting.
What does ServiceNow do by default when coalesce finds multiple matching records?
C is correct. Coalesce requires a unique match. When multiple existing records match the coalesce key value, ServiceNow cannot determine which record to update — the import row is marked as an error and skipped. It does not arbitrarily pick one (B), create a new record (A), or merge records (D). Preventing multiple matches requires maintaining data uniqueness on the coalesce field in your target table.
When does an onComplete script execute?
B is correct. The onComplete script fires once after the entire transform run finishes — all rows processed. It is used for post-import actions like sending a summary notification, triggering a follow-up workflow, or updating a "last import" timestamp. Compare with: onBefore script (fires before each row), onAfter script (fires after each row), and onReject (fires when a row is rejected). These are distinct hooks with different timing.
[TRAP] What is the most likely root cause?
B is correct. The most common real-world coalesce failure is whitespace mismatch. If staging data has " john@example.com" (with a space) and the target has "john@example.com", they do not match — so coalesce silently falls through to a CREATE. Other causes: case mismatch (if case-sensitive), wrong field mapped for coalesce, or the Transform Map action set to Insert Only (D — also a valid answer, but the "everything looks correct" clue points to a data quality issue). Always trim staging data before coalesce fields.
source.What does the source variable refer to in a Transform Map script?
B is correct. In Transform Map scripts, three key objects are available: source = the current staging row (GlideRecord of the import set table — the input), target = the target record being created/updated (GlideRecord of the production table — the output), and answer = the output value for field-level scripts. source.u_email reads the staging email column. target.email reads/writes the production email field. Confusing source and target is a common exam trap.
serial_number as the coalesce field, and (2) a ServiceNow Discovery run. Both target the same cmdb_ci_server records. After both run, some field values toggle between the two sources' values on each run cycle.Why does the Import Set approach create this "value toggling" problem, and which Part 4 engine prevents this for Discovery?
B is correct. Import Set Transform Maps use simple coalesce (find existing record → update all mapped fields). If two sources both map the same field, the last one to run wins — producing the toggling. IRE (Part 4) uses Reconciliation Rules to define SOURCE AUTHORITY per field: "Discovery owns cpu_count; Import Set owns warranty_end" — each source can only win its authorized fields. IRE is not automatically invoked by Import Set transforms; you'd need to call the IRE API explicitly for multi-source reconciliation.
Which statement correctly describes MID Server requirements for these two scenarios?
B is correct. A MID Server bridges ServiceNow's cloud instance to a private network that ServiceNow cannot reach directly. On-premises servers behind a firewall require a MID Server as the on-premises proxy. AWS public APIs (EC2, RDS, CloudWatch) are internet-accessible — the SGC calls them from ServiceNow's cloud without a MID Server. This connects Part 2 (SGC, Topic 5) with Part 3 (MID Server, Topic 2).
What problem are both solving, and what is the key advantage IRE Identification Rules provide over a simple coalesce field?
B is correct. Coalesce (Part 2) and IRE Identification Rules (Part 4) both answer "does a CI for this device already exist?" — if yes, update it; if no, create it. But IRE goes further: multiple identifier priority chains, CI class-specific rules, and integration with Reconciliation (who owns which field) and Deduplication (merge near-duplicates). Coalesce is sufficient for simple single-source loads. IRE is required for multi-source, multi-authority CMDB management.