ServiceNow import sets provide a controlled path for loading external data without writing directly to production tables. The pattern is simple: load source data into a staging table, apply a transform map, then inspect the target records. The implementation details determine whether the result is repeatable or becomes a stream of duplicates, slow transforms, and difficult support tickets.
Use the following ServiceNow import set and transform map best practices for migrations, scheduled imports, and inbound integrations.
1. Profile the Source Before You Configure the Import
Start by documenting the source columns, data types, required values, expected row count, and known quality issues. Decide how to handle blank identifiers, invalid dates, duplicate source rows, and values that do not exist in ServiceNow reference tables.
Create a simple mapping specification with four columns: source field, target field, transformation, and rejection rule. This turns assumptions into reviewable decisions and prevents transform scripts from becoming the first place anyone documents the logic.
2. Keep the Staging Table Close to the Source
A staging table is an inspection layer, not a second target data model. Preserve the source values with minimal changes when the data is loaded. Perform normalization in field maps or transform scripts so administrators can compare the original row with the transformed result.
Use clear column names, but avoid adding calculated fields unless they make troubleshooting materially easier. Retaining raw values is especially useful when a date fails to parse or a reference lookup produces an unexpected match.
3. Choose a Stable Coalesce Key
Coalesce tells the transform map how to detect an existing target record. If a match is found, the transform updates it; otherwise, the transform normally inserts a record. A weak key can merge different records or create a duplicate every time an identifier changes.
Prefer an immutable business identifier from the system of record, such as an employee number, asset tag, or external correlation ID. Avoid names, descriptions, and email addresses when they can change or are not guaranteed to be unique.
If the identity requires multiple fields, document the complete key and test partial or blank combinations. Configure the transform's behavior for empty coalesce fields deliberately rather than accepting a default without review.
4. Index the Target Fields Used for Coalesce
Each coalesce lookup must find a target record. On a large table, repeatedly searching unindexed fields can make an import unnecessarily expensive. ServiceNow guidance recommends that coalesce fields be indexed, and the platform provides an Index Coalesce Fields related link for checking whether a suitable index is required.
Confirm uniqueness before requesting an index. An index improves lookup efficiency; it does not repair a business key that identifies several records.
5. Prefer Field Maps Over Custom Scripts
Use standard field maps for direct assignments, reference mappings, and simple value transformations. They are easier to review than a large transform script and show administrators exactly which source column feeds each target field.
Add scripts only when declarative mapping cannot express the rule. Keep each script focused, name its purpose in comments, and avoid hidden GlideRecord queries inside per-row logic. A query that looks harmless in a test of 20 rows can become a serious load when the file contains 100,000 rows.
6. Use Transform Events for the Right Scope
Transform event scripts run at different points in the import lifecycle. Use onBefore for row-level validation or to ignore a row before it is written. Use onAfter only for work that depends on the saved target row. Reserve onComplete for actions that should happen once after the full import finishes.
Do not put batch-wide calculations in onAfter; they will run once for every row. Likewise, do not use an onComplete script when each row needs an independent validation decision.
7. Decide Whether Business Rules Should Run
The Run business rules option can invoke business rules, workflows, approval engines, auditing, and field normalization while target records are inserted or updated. That may be essential for data integrity, or it may trigger notifications and automation that a bulk load should avoid.
Review the target table's server-side logic before deciding. If you disable business rules for performance or side-effect control, explicitly recreate only the required outcomes in the import design. Test both the record values and downstream effects in a sub-production instance.
8. Protect Existing Values From Empty Source Fields
The Copy empty fields setting can clear an existing target value when the incoming field is empty. That may be correct for a full authoritative feed but dangerous for a partial update.
Classify each integration as a full snapshot or a delta. For a delta, map only fields the source actually owns and guard against blanks that mean “not supplied” rather than “remove this value.” Include null, empty-string, and whitespace-only cases in testing.
9. Validate Results, Not Just the Completion Code
ServiceNow's developer training notes that a transform completion code of Success means the transform executed; it does not prove that the imported records are correct. Review transform history, row errors, inserted and updated counts, ignored rows, and representative target records.
Reconcile the outcome with the source:
- Source rows = inserted + updated + ignored + errored rows
- Expected updates match the number of existing business keys
- Mandatory and reference fields contain valid values
- A second run produces updates instead of unexpected duplicates
That last rerun is a practical idempotency test and should be part of acceptance testing for every recurring import.
10. Build Operational Guardrails
Run first in a sub-production instance with production-like volume. For recurring loads, define ownership, schedule, expected duration, failure notification, retry behavior, and retention for staging data. Stagger large imports so they do not compete with clones, discovery schedules, or other heavy jobs.
Log a concise run summary that operators can act on: source name, import set, row totals, duration, and error count. Alert on exceptions rather than sending a success email no one reads. When the source contract changes, update the mapping specification and regression tests before the next scheduled execution.
Final Thoughts
A reliable ServiceNow import is designed as a data pipeline, not treated as a one-time upload. Preserve the source in staging, select a stable indexed coalesce key, prefer transparent field maps, scope scripts carefully, and verify the resulting records.
Most importantly, run the same data twice during testing. If the second pass creates duplicates, clears valid values, or triggers unwanted automation, the transform is not ready for production.