Configuration on a ServiceNow instance is just data — rows in metadata tables like sys_dictionary, sys_script, sys_ui_action. To promote changes safely from your development instance to test, then to production, ServiceNow uses update sets. Understanding update sets is mandatory for the CSA exam and for working safely in any multi-instance environment.
The Three-Instance Model
dev (sandbox) → test (staging) → prod (live users)
(build) (validate) (release)Engineers configure on dev. Update sets capture the changes. Those update sets are exported (or read remotely), previewed, then committed on the next environment. Mature shops add a separate "uat" instance between test and prod.
What an Update Set Tracks
An update set captures changes to configuration tables:
- Tables, fields, and dictionary entries
- Forms, sections, and UI policies
- Business rules, script includes, client scripts
- ACLs and roles (but not users or group membership)
- Catalog items, variables, and workflows / flows
- Notifications, email templates, and email scripts
- Reports and dashboards (with caveats)
What an Update Set Does NOT Track
Critical to understand — these are data, not configuration, and you must move them separately:
- Records on tables like incident, problem, sc_request — i.e., transactional data
- Users (sys_user)
- Groups and group membership
- CMDB CI records
- Knowledge articles
- Attachments
To move data, you either:
- Use a clone (full database refresh from prod to lower environments)
- Use XML export/import for individual records
- Use the Data Provider feature for bulk data migration
Update Set Mechanics
Creating an update set
Before making changes, switch your current update set to a new, named set (e.g., "PROJ-1234 Add VPN catalog item"). Every change you make while that update set is current is captured in it.
The current update set indicator is shown at the bottom of the screen on classic UI; use it to verify before you start work. Forgetting to switch is the #1 cause of "missing changes" in the next environment.
Closing an update set
When development is done, mark the update set Complete. This locks it from further additions. Completed update sets can then be retrieved on the target instance.
Retrieving and previewing
On the target (test/prod) instance:
- Set up a retrieve URL pointing back to the source instance (one-time)
- Retrieve completed update sets from that source
- Preview the update set — this is the critical step
- Resolve any preview errors or conflicts
- Commit the update set
Preview Errors
The preview step compares each item in the update set against the current state of the target. Common error types:
| Issue | Cause | Resolution |
|---|---|---|
| Local change exists | Someone modified the target instance directly | Accept remote, skip, or merge manually |
| Could not find a record | The update references a sys_id that doesn't exist on the target | Move the referenced record first via XML or include in the set |
| Update set already committed | You're applying a duplicate | Cancel and verify history |
Never bypass preview errors by committing blindly. A bypassed error in dev often becomes a broken form in prod.
Batching
Multiple update sets can be grouped into a batch. The batch is committed as one unit, ensuring atomicity across related changes. For a feature spanning multiple update sets (e.g., "VPN catalog item + new role + new approval workflow"), batching reduces the risk of partial commits.
Backout
Each committed update set can theoretically be backed out. Backout replays the captured "before" state of each record. This is not always safe:
- If subsequent changes depend on the update, backout will create inconsistency
- Data-affecting business rules cannot be backed out (their effects persist)
- Records created by the update set are not deleted on backout
Treat backout as a last-resort safety net, not a routine option. Most production teams forward-fix rather than back out.
Scoped Applications: A Different Model
For custom-built applications, ServiceNow recommends building them as scoped applications. Scoped apps have:
- A unique scope name (e.g.,
x_acme_proc) - All their tables, scripts, and metadata prefixed with that scope
- Cleaner upgrade behaviour
- The ability to be published to the Application Repository and installed on other instances directly
For scoped apps, you can also use ServiceNow's Source Control integration (Git) — commit to a Git repository from inside Studio, pull on the target instance, deploy. This makes scoped apps closer to traditional software development than the update set model.
Best Practices
- One update set per work item — match it to your Jira/Asana ticket
- Always switch your current update set before starting work
- Never edit configuration directly on prod or test — only commit promoted update sets
- Use batching for related multi-set features
- Document the order of update sets when they have dependencies
- Review preview errors carefully — they exist for a reason
- Clone down from prod regularly to keep dev representative
Try It on Your PDI
- Create an update set called "Practice Lesson 7"
- Switch to it as your current update set
- Add a custom field to the Incident form (e.g., "External Reference")
- Mark the update set Complete
- Export the update set as XML (System Update Sets > Local Update Sets > right-click > Export to XML)
- Inspect the XML — see how each captured change is serialised
The XML format is human-readable and helps you understand what update sets actually contain.