Update Sets and Source Control. These two tools solve one of the messiest problems in ServiceNow development: how to move changes from one environment to another without breaking everything or losing your work. For the SNOW-CAD exam, you need to understand that Update Sets are the native ServiceNow way to bundle customisations for migration, while Source Control (usually Git) is the more modern, industry-standard alternative for managing code changes across a team.
Jump to a section
A simple way to picture Update Sets and Source Control
Have you ever been the one put in charge of the playlist for a friend's wedding? You have a shared Spotify account, and everyone wants to add their favourite songs. You make changes: you add 'Uptown Funk', you remove that fifth version of 'Despacito', you reorder the first dance songs. But disaster strikes—someone accidentally deletes the entire 'Reception Party' playlist. How do you get it back without starting from scratch, and how do you know who made which change?
This is exactly the problem that Update Sets and Source Control solve for ServiceNow developers. The wedding playlist is your ServiceNow instance—the platform where you build apps. Each song you add is a 'customisation' or a 'configuration change', like creating a new field on a form or writing a business rule. Spotify's 'version history' is like an Update Set: it captures every change you made, packed up neatly, so you can roll back or replay it on another account. The shared Spotify account is akin to a 'Source Control repository' (like Git), where every change is tracked, named, and reversible.
If the DJ accidentally removes the playlist, you don't panic—you restore from the saved version. Likewise, an IT pro can 'commit' a set of changes (an Update Set) to source control, then 'deploy' them to a different environment without losing data. The analogy holds perfectly: you control who edits, you track what changed, and you always have a backup plan. Without this system, updating a ServiceNow application would be like trying to DJ a wedding by shouting song requests from the dance floor—chaotic, irreversible, and likely to end in tears.
Let’s start by defining the core problem. When you build an application in ServiceNow, you don't build it directly on the live system used by real users. That would be like painting a wall while your family is still living in the room—disaster. Instead, you work in separate 'environments'. The most common setup is a 'Dev' environment where you build and test, a 'Test' or 'QA' environment where the quality team checks your work, and a 'Production' environment where real users do their jobs. The challenge is: how do you get your changes from Dev, through Test, and into Production safely? You cannot just copy and paste configurations. That is where Update Sets and Source Control come in.
What is an Update Set?
An Update Set is a container—like a shopping basket—that collects all the changes you make to a ServiceNow instance. Every time you create a new field, modify a business rule, change a workflow, or alter a form layout, ServiceNow can track that change and add it to your current 'shopping basket'. When you are finished making changes, you 'commit' or 'export' the Update Set. The exported file (a compressed XML file) contains a precise list of every modification, enough information to reapply those changes on another instance.
Update Sets have two main types: - Default Update Sets (also called 'outbound' update sets): These capture changes you make in your current instance, intended to be moved to another instance. - Retrieved Update Sets (also called 'inbound' update sets): These are update sets you have imported from another instance, ready to be previewed and applied.
Once you import an Update Set into a target instance (like Test or Production), you can 'preview' it to see what will change (a preview shows you the differences between the current state and the incoming changes). Then you 'commit' it to apply the changes. If something goes wrong, you can roll back by reverting the committed Update Set.
What is Source Control?
Source Control (also called 'Version Control' or 'SCM'—Source Code Management) is a system that tracks every change to a set of files over time. Think of it like a detailed diary for your code. The most popular system is Git (with providers like GitHub, GitLab, or Bitbucket). In Git, you 'commit' snapshots of your work, and you can 'push' those commits to a remote server so your team can see them, and 'pull' changes made by others.
ServiceNow integrates with source control through something called the 'Application Repository'. Instead of using ServiceNow's proprietary Update Set format, you can connect your dev instance directly to a Git repository. When you make a change (like creating a new field), that change is automatically turned into a file on your local machine, which you then commit and push to Git. This gives you a full history, branching (so you can work on features separately), and the ability to collaborate with a team without overwriting each other's work.
How They Compare
Update Sets are simple, native, and require no external tools. They work well for lone developers or small teams, especially if you don't have a Git server. However, they have limitations: they don't give you a granular file-by-file history, they can be hard to merge if two people work on the same thing, and they are ServiceNow-specific (you can't use them with other platforms).
Source control is more powerful. It gives you a complete audit trail, conflict resolution (when two people edit the same file, Git helps you manually choose which changes to keep), and it's a standard skill across the entire software industry. Many companies now require using Git even for ServiceNow development.
An Example Walkthrough
Imagine you are building a custom 'Vacation Request' app in ServiceNow. You start in your Dev instance:
You create a new table called 'Vacation Request'.
You add fields: 'Start Date', 'End Date', 'Reason'.
You write a Business Rule that automatically calculates the number of days.
You create a UI Policy that hides the 'Reason' field unless the request is for more than 3 days.
Without Source Control (using Update Sets only): - You set your Default Update Set to 'My Vacation App v1'. - ServiceNow tracks all four changes into that set. - You export the Update Set XML file and email it to your colleague. - They import it into the Test instance, preview it, and commit it. - If you now make more changes, you start a new Update Set.
With Source Control (using Application Repository): - You clone the remote Git repository to your local machine. - You connect your ServiceNow instance to the repository. - Every time you create a field or rule, ServiceNow creates a corresponding file (e.g., a .xml or .json file) on your local machine. - You commit those files to your local Git repository with a message like 'Added Vacation Request table and fields'. - You push those commits to the remote Git repository. - Your colleague pulls the changes, and they automatically appear in their instance. - If two of you changed the same file, Git will tell you there is a conflict, and you can manually decide what to keep.
Why This Exists
Before Update Sets and Source Control, developers had to manually document every change they made and copy it to other environments—a process called 'change management' that was slow and error-prone. A missed step could break the entire production system. Update Sets automated the capture and application of changes, reducing human error. Source control took it further by adding collaboration features and a full history, making it possible for dozens of developers to work on the same application without stepping on each other's toes.
For the SNOW-CAD exam, you will be asked to differentiate between these two approaches, understand the lifecycle of an Update Set (from 'In Progress' to 'Committed'), and know the basic terms like 'remote repository', 'commit', 'push', and 'pull'.
Create a Named Update Set
In your Dev instance, navigate to 'Update Sets' and click 'New'. Give it a descriptive name (e.g., 'Vacation Request App v1.0'). This becomes your active shopping basket. Without this step, your changes would go into the global set, making them harder to export and manage.
Make Your Changes
Create or modify any ServiceNow configuration—tables, fields, business rules, UI policies, etc. Every change you make is automatically captured and added to your active update set. Check the 'Update Set' field on changed records to confirm they are included.
Complete and Export the Update Set
When you finish making all changes for this feature, change the update set's state from 'In Progress' to 'Complete'. This tells ServiceNow you are done editing. Then click 'Export to XML' to download a compressed XML file containing all the changes. This file can be shared via email, shared drive, or imported into another instance.
Import and Preview on Target Instance
Log into the target instance (e.g., Test or Production). Navigate to 'Retrieved Update Sets' and import the XML file you exported. Select the imported update set and click 'Preview'. ServiceNow will simulate the changes and show you any conflicts (if the same record was modified differently elsewhere). Review the preview carefully.
Commit the Update Set
If the preview looks correct, click 'Commit' to apply the changes. ServiceNow will make all the modifications to the target instance. You can verify by checking the records. If something goes wrong, revert the update set by clicking 'Rollback' (available as long as no other update sets have been committed on top of it).
An IT professional working with ServiceNow might start their day like this: Sarah logs into her company's Dev instance where she is building a custom approval workflow for expense reports. Before she makes any changes, she checks her assigned 'Default Update Set'—she always creates a new one for each feature, naming it clearly, e.g., 'Expense Approval Workflow v2.3'.
She works for two hours: she modifies a Business Rule, creates two new fields on the Expense Report table, and adjusts a dashboard. Each change is automatically captured by the update set. At lunchtime, she goes to 'Update Sets > Local Update Sets' and clicks 'Export to XML'. She saves the .xml file to her shared drive. After lunch, she imports that same file into the Test instance. She previews it first, which checks for conflicts—maybe someone else already added one of those fields. She resolves a conflict by choosing to keep the new field's definition from her update set, then commits it. She sends a quick message to the QA team: 'Update set deployed to Test for validation.'
Later that week, her company decides to switch to Git-based source control for all ServiceNow development. The lead developer creates a new Git repository and shows Sarah how to connect her instance to it using the 'Studio' tool. Now, instead of exporting XML files, she clones the repo, opens Studio, and every change she makes automatically creates a file in a local folder. At the end of a feature, she commits and pushes her work. The team uses 'branches' to work on separate features—so Sarah's feature branch is called 'feature/expense-approval-2.3'. She opens a 'pull request' when her work is ready for review, and a senior developer checks her code before merging it into the main branch. The merge then triggers an automated process that deploys her changes to the Test environment. This is faster, more secure, and every change is permanently tracked with a timestamp and the developer's name.
The same IT pro might also need to migrate an application from one ServiceNow instance to another (say, from a testing environment to production). She would:
Use an update set if the environments are not connected via source control.
Use the 'Application Repository' if both instances are connected to the same Git repo.
Or, in more advanced setups, use ServiceNow's 'CI/CD' (Continuous Integration/Continuous Deployment) pipeline, which automates the whole process using source control as the trigger.
In either case, the professional never makes changes directly to the Production instance. That is a cardinal rule. All changes must be captured, tested, and applied through a controlled migration process.
The SNOW-CAD exam tests Objective 8.1 thoroughly. Expect multiple-choice questions that assess your understanding of the Update Set lifecycle, how to move update sets between instances, and the basics of source control integration.
Specific topics the exam loves to test: - The two types of Update Sets: 'Default' (local, for changes you make) and 'Retrieved' (imported from another instance). - The states of an Update Set lifecycle: 'In Progress' (actively capturing changes), 'Complete' (you have finished working on it), 'Previewed' (a preview has been generated on the target instance), and 'Committed' (the changes are applied). - The difference between 'Export to XML' and 'Export to Update Set' (both exist but the exam focuses on XML export as the primary method). - The requirement that you must be in an Update Set for changes to be captured—if you are in the default 'Global' update set, changes will still be captured but not grouped effectively. The exam will test that you understand to create a named update set for each distinct project. - 'Conditional Update Sets': not tested on the exam, so ignore them. - Source control concepts: 'commit', 'push', 'pull', 'remote repository'. The exam asks you to identify which command does what. - The 'Application Repository' feature: how to enable it and the requirement for a connection to a Git repository.
Traps the exam sets: - Trap 1: They ask 'Can you commit an update set without previewing it first?' The answer is yes—you can, but it's risky. The exam expects you to know previewing is a best practice, but not mandatory. - Trap 2: They present a scenario where a developer makes changes without being in an update set. The trap is that those changes are still captured in the default 'Global' update set, they are not lost—many beginners think changes are not tracked at all if you forget to create a named update set. - Trap 3: They confuse 'Export to XML' with 'Export to Repository'. The exam tests that you know exporting to repository sends the update set to a source control system, while XML export creates a file you can share manually. - Trap 4: They ask 'Which two types of update sets exist?' and list distractors like 'Private' and 'Public' (no such things). Correct answer: Default and Retrieved. - Trap 5: A question about 'What happens when you commit an update set in the target instance?' The answer: the changes are applied and cannot be easily undone (though you can roll back via update set revert, which is a separate feature).
Key definitions to memorise: - Update Set: a container that groups a set of customisations for migration. - Preview: a simulation of what will change when you commit an update set. - Commit: the act of applying the changes from an update set to the instance. - Source Control: a system that tracks changes to files over time. - Git: a specific source control system. - Repository: a central location where source code is stored and managed. - Remote Repository: a repository hosted on a server (like GitHub) that multiple developers access. - Commit (verb): saving a snapshot of changes to the local Git repository. - Push: uploading local commits to a remote repository. - Pull: downloading changes from a remote repository to your local system.
An Update Set is like a shopping basket that collects all your ServiceNow customisations so you can move them between instances safely.
You must be in a named update set (not the default global one) to keep your changes organised and migrate them cleanly.
The four main states of an update set are: In Progress, Complete, Previewed, and Committed.
Source control (Git) provides a full history of every change and allows multiple developers to work on the same application without conflict.
Previewing an update set before committing it is a best practice to avoid breaking the target instance with unexpected changes.
You can revert a committed update set using the Rollback feature, but only if no other changes have been made on top of it.
ServiceNow's Application Repository links your instance to a Git repository, combining the simplicity of update sets with the power of source control.
Never make changes directly to a Production instance — always use Update Sets or Source Control to migrate changes from Dev through Test to Production.
These come up on the exam all the time. Here's how to tell them apart.
Update Set
Captures changes in a single container, not individual files.
No automatic history of who changed what or when (only a description field).
Export produces a single XML file, difficult to merge if two people work on the same set.
Source Control (Git)
Tracks changes per file, giving a granular history.
Full audit trail with timestamps and author names for every commit.
Each commit is a snapshot, and merging conflicts is a built-in feature.
Export to XML
Creates a downloadable .xml file for manual sharing.
No dependency on external tools or servers.
Workflow-centric: export, send, import, commit.
Export to Repository
Sends update set data to a remote Git repository.
Requires a configured connection to a Git server (e.g., GitHub, GitLab).
Enables team collaboration through pull requests and branching.
Default Update Set
Created in the local instance to capture changes you are making now.
State starts at 'In Progress' and you complete it manually.
Used for exporting changes out of the current instance.
Retrieved Update Set
Comes from another instance (imported from an XML file or repository).
State starts as 'Loaded' and you preview/commit it to apply changes.
Used for bringing changes into the current instance.
Preview an Update Set
Simulates the changes without applying them.
Shows a list of what will be created, updated, or deleted.
Can be run multiple times; no permanent effect on the instance.
Commit an Update Set
Applies the changes permanently (until rolled back).
Executes the actual modifications to the instance's database.
Can only be done once per update set (unless rolled back and recommitted).
Mistake
If I don't create a named update set, my changes will not be captured at all.
Correct
Changes are always captured, but they go into the default 'Global' update set. The problem is that the global set accumulates everything, making it messy and hard to migrate just the changes you want.
Beginners often think tracking is optional. In reality, ServiceNow tracks everything automatically, but the lack of organisation in the global set is bad practice.
Mistake
Update Sets and Source Control are two completely separate systems that don't interact.
Correct
They can work together. ServiceNow's Application Repository allows you to export update sets to a Git repository, effectively using update sets as the format for changes and Git as the storage and collaboration platform.
The exam teaches them as distinct concepts, so learners often see them as mutually exclusive. In practice, many organisations use both together.
Mistake
Once an update set is committed, you can never undo it.
Correct
You can revert a committed update set. ServiceNow includes a 'Rollback' feature that undoes the changes that were applied. However, it only works if the update set itself hasn't been further modified by other commits.
This misconception comes from the term 'commit' sounding final, like Git commits which are not easily undone. ServiceNow's commit is more like 'apply' and is reversible.
Mistake
You can 'preview' an update set only after you commit it.
Correct
You preview an update set before committing it. The preview is a safety step that shows you what will change. You can commit only after previewing (or skip previewing, but that's not recommended).
The order of operations is confusing: users think preview is part of the commit process, but it's actually a separate preparatory step.
Mistake
Every time you make a change to a record, it is automatically added to the current update set without exception.
Correct
Most changes are captured automatically, but some configuration changes (like certain system properties or plugin activations) may not be captured, depending on the type of change. Always check that your change appears in the update set before exporting.
Beginners assume the system is perfect. In reality, some low-level changes are not trackable by update sets, leading to surprises during migration.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An update set is a container that groups a set of changes you make to a ServiceNow instance. It captures things like new fields, business rules, and form layouts, so you can export them as a single package and apply them to another instance.
Yes, ServiceNow supports source control integration through the Application Repository feature. You can connect your instance to a Git repository (like GitHub or GitLab) and manage changes using standard Git commands like commit, push, and pull.
No, it's not mandatory, but it is a best practice. Previewing shows you what changes will be applied and highlights any conflicts. Skipping preview risks applying unintended changes to the target instance.
They are still captured, but they go into the default 'Global' update set. That set accumulates every change you make, making it messy and unsuitable for migrating a specific feature cleanly. Always create a named update set for each project.
Yes, you can revert a committed update set using the Rollback feature. This undoes all the changes applied by that update set. However, it only works reliably if no other update sets have been committed on top of it.
'Export to XML' creates a file on your computer that you can manually share with others. 'Export to Repository' sends the update set to a connected source control repository (like Git) for more collaborative version management.
You've finished Update Sets and Source Control. Continue through the SNOW-CAD study guide to build a complete picture of the exam.
Done with this chapter?