# Updates and Release Management

> Chapter 17 of the Courseiva SERVICENOW-CSA curriculum — https://courseiva.com/learn/servicenow-csa/updates-and-release-management

**Official objective:** 4.3 — Manage updates, patches, and release cycles including update sets and application migration.

## Introduction

How do you make changes to a live ServiceNow system without breaking the login screen for thousands of users? That is the problem Updates and Release Management solves, and it is one of the most practical skills tested on the SNOW-CSA exam. You need to understand how IT teams safely move new features, bug fixes, and security patches from a developer's sandbox all the way to the production environment that users rely on every day.

## The Kitchen Renovation Analogy

Your friend's kitchen, a chaotic space with mismatched cabinets and a leaking faucet. You and another friend decide to fix it up. The problem is, you both live in different cities. You cannot just lean over and hand each other a screwdriver. Instead, you each work separately on your own parts.

You build a new set of cabinet doors at your place, carefully tracking each piece in a box labelled 'Kitchen Cabinet Set A'. Your friend, across town, rewires the under-cabinet lights and packs his work into a box labelled 'Lighting Kit B'. These boxes are your update sets. When your cabinet doors are finished, you mail them to a central storage unit, not directly to the kitchen. This storage unit is the 'target instance' – the real kitchen where everything must finally fit. You also write a note for the label: 'Works with Version 2.0 of the kitchen layout' because your friend is building to a different floor plan than you originally thought.

Once all the boxes arrive at the storage unit, you both go there. You open 'Kitchen Cabinet Set A' and review if it still fits the current floor plan. You see a note that it conflicts with 'Lighting Kit B'. You fix the conflict by modifying a mounting bracket. Only after you have checked and resolved every conflict do you carry the finished cabinets and lighting from the storage unit into the actual kitchen and install them. That final install is the 'commit'.

## Core explanation

When you log into a ServiceNow instance, you are using a specific environment. An environment is just a copy of the ServiceNow platform running on a server. Most companies have at least three environments: development, test, and production. Development is where coders build new stuff. Test is where quality assurance people try to break that new stuff. Production is the live system that employees and customers actually use. You never, ever build or test directly in production because if you make a mistake there, you break the real system.

So how do changes travel from development to production? They do not fly through the air. They travel in packages called update sets. An update set is a container that captures all the modifications you made in one environment. If you create a new field on a form, change a business rule, or configure a notification, ServiceNow records that change and adds it to the active update set. Think of an update set as a carefully packed suitcase. You pack everything you changed into that suitcase, then you move the suitcase to the next environment.

Here is the key workflow. First, you set your update set to 'Complete' when you finish work in development. Completing an update set locks it, meaning you cannot accidentally add more changes to it. Then you export that update set as an XML file. Exporting creates a downloadable file that contains all the instructions to recreate your changes. Next, you import that XML file into your test environment. The import process reads the instructions and applies them. If there is a conflict, meaning the test environment already has a different version of the same thing you changed, ServiceNote does not just overwrite it blindly. It tells you about the conflict so a human can decide which version to keep. This is called conflict resolution.

Once the update set passes testing, you move it to production using the same import and commit process. 'Committing' an update set means permanently applying it to the environment. After commit, the changes are live and you cannot roll them back using the update set mechanism. You would have to create a new update set to undo the change.

There is also a newer way to move changes called Application Migration. Application Migration uses a different concept called an application. An application is a collection of related updates that form a feature or product. Instead of moving individual update sets, you move the entire application from one environment to another. Think of an update set like a single suitcase, while an application is like a shipping container. The shipping container can hold multiple suitcases plus some extra packaging. Application Migration is more modern and powerful, but the SNOW-CSA exam still tests heavily on classic update sets because they are so widely used.

Why does all this exist? Because untracked changes cause chaos. Imagine five developers all editing the same form at the same time. Without update sets, the last person to save wins, and the other four people's work disappears. Update sets give each developer their own private workspace. Each developer works in their own update set. When they move their update sets into a common environment, the system checks all the changes together and surfaces conflicts before anything breaks. This is the foundation of release management, which is the discipline of planning, scheduling, and controlling the movement of updates through your environments.

## Real-world context

An IT administrator named Priya works for a mid-sized company that uses ServiceNow for IT support. The company has a new policy: all employees must use a new 'Data Privacy' checkbox on the incident form when they log a ticket about a personal data issue. Priya needs to build this checkbox in development, test it, then get it into production within two weeks.

Priya starts by logging into the development instance. Before she makes any changes, she opens the update sets module and creates a new update set called 'Data Privacy Checkbox v1'. She sets this as her current update set. Now every change she makes gets captured inside that container. She navigates to the incident form, adds the checkbox field, and configures it so it only appears for certain categories of incidents. She also writes a small business rule that sends an email to the privacy team when the box is checked. All of these changes are automatically recorded in her update set.

When Priya finishes, she sets the update set to 'Complete'. Then she exports it as an XML file and sends it to her colleague in the test team. The test team imports the XML file into the test environment. When they try to commit the update set, ServiceNow shows a conflict: the test environment already has a version of the business rule that Priya edited. Someone changed it during a different project. Priya reviews the conflict, picks the version that should survive, and commits the merged version.

After the test team approves, Priya exports the update set again from development (or from test, depending on the company's process) and moves it to production. In production, she imports the XML file and commits it during a scheduled maintenance window. The checkbox goes live. The next day, an employee logs a ticket about a data breach, sees the checkbox, and checks it. The privacy team gets an automatic email. The process worked because every change was tracked, reviewed, and moved in a controlled way.

What could go wrong? If Priya had forgotten to set the current update set before starting, her changes would have gone into the 'Default' update set. The default update set is like a junk drawer — it catches everything but makes it nearly impossible to export and move cleanly. If she had tried to commit directly in production without testing, she might have broken the incident form for all users. If the team had no conflict resolution process, they might overwrite each other's work and lose changes. That is why real IT departments enforce strict policies around update set naming, review approvals, and scheduled release windows.

## Exam focus

The SNOW-CSA exam tests Updates and Release Management in several specific ways. First, you will see scenario questions where you are given a description of a change and asked to identify the correct sequence of steps. For example: 'A developer has completed work on a new catalog item in the development instance. What should they do next?' The correct answer is to mark the update set as Complete and then export it. A common trap is an option that says 'Commit the update set in development.' You never commit an update set in the development instance — you complete it and export it. Committing happens in the target environment, not the source environment.

Second, the exam tests the difference between update sets and application migration. Update sets are created manually by developers and moved as XML files. Application migration uses an automated pipeline called the Application Repository. You need to know that Application Repository stores applications in the ServiceNow cloud and allows you to install them on other instances directly, without exporting XML files. The exam will ask you to identify which method is appropriate for which situation. For simple, small changes, update sets are fine. For large, multi-scope applications, Application Migration is preferred.

Third, the exam tests conflict resolution. You must understand that conflicts happen when two update sets modify the same element, like the same form field or the same business rule. ServiceNow detects conflicts during the import or commit process. The system does not automatically resolve conflicts — it flags them and asks a human to decide. The exam will give you a scenario with a conflict and ask what the administrator should do. The correct answer is always something like 'Review the conflicting updates and select which version to keep' or 'Manually resolve the conflict before committing.'

Fourth, the exam tests the update set lifecycle states. You need to memorise the five main states: In Progress, Complete, Ignored, Committed, and Cancelled. 'In Progress' means the developer is still adding changes. 'Complete' means no more changes can be added and it is ready for export. 'Committed' means it has been applied to the target environment. The exam will hide these states in multiple-choice options and test whether you know which state applies to a given step in the process.

Finally, the exam tests best practices. Do not commit update sets that have errors. Always test in a non-production environment before committing to production. Always set an update set to current before making changes. Name update sets descriptively so other administrators know what they contain. The exam will present a list of actions and ask which one is a violation of best practice. The incorrect option will be something like 'Committing an untested update set directly to production.' Trap options often involve skipping the test environment or ignoring conflict warnings.

## Step by step

1. **Set Current Update Set** — Before making any changes in the development instance, you navigate to the Update Sets module, create a new update set with a descriptive name, and set it as 'Current'. This tells ServiceNow to track every modification you make and store it inside this container.
2. **Build and Capture Changes** — You make your configuration changes, such as adding fields, editing business rules, or creating catalog items. ServiceNow automatically records each change in the current update set. You can verify what has been captured by viewing the update set's 'Update Set Preview' or 'Customer Updates' related list.
3. **Mark as Complete and Export** — When all changes are finished, you set the update set state to 'Complete'. This locks the update set to prevent accidental additions. You then export the update set as an XML file, which is a portable format that can be imported into another ServiceNow instance.
4. **Import into Test Environment** — You log into the test instance, navigate to the Update Sets module, and use the 'Import Update Set from XML' option to upload the file. The system processes the XML and prepares the changes for application. Any conflicts are flagged during this step.
5. **Resolve Conflicts and Commit** — If conflicts exist, you review each one and choose which version to keep. After conflicts are resolved, you commit the update set. Committing applies the changes permanently to the test environment. You then run tests to validate everything works correctly.
6. **Promote to Production** — After successful testing, you export the update set from the test instance (or the original development instance if the process dictates) and import it into the production instance. You resolve any new conflicts that arise and commit during a scheduled maintenance window. After commit, the changes are live for all users.

## Comparisons

### Update Set vs Application Migration

**Update Set:**
- Captures changes as a list of individual 'customer updates'
- Exported as an XML file for manual transfer between instances
- Best for small, discrete changes like a single form field or business rule

**Application Migration:**
- Migrates an entire application as a structured unit
- Uses the Application Repository for automated, cloud-based transfer
- Best for large, multi-scope applications built with App Engine Studio

### Development Instance vs Production Instance

**Development Instance:**
- Used for building and testing new changes without risk to live users
- Changes are captured in update sets but are not committed here
- Often has relaxed security to allow developer flexibility

**Production Instance:**
- The live system used by employees and customers
- Changes are applied only after thorough testing and approval
- Has strict security and access controls to prevent accidental breakage

### Complete State vs Committed State

**Complete State:**
- Locks the update set so no more changes can be added
- Happens in the source environment (usually development)
- Prepares the update set for export and migration

**Committed State:**
- Permanently applies the update set's changes to the target environment
- Happens in the target environment (test or production)
- Cannot be undone; changes are live and require a new update set to reverse

### Default Update Set vs Named Update Set

**Default Update Set:**
- Automatically captures changes if no other update set is set as current
- Cannot be exported or managed as a discrete unit
- Considered a 'junk drawer' for untracked changes

**Named Update Set:**
- Manually created with a descriptive name before making changes
- Can be exported, imported, and committed independently
- Best practice for all development work to maintain traceability

## Diagram

_This flowchart shows the complete lifecycle of an update set from creation in development to commitment in production._

```mermaid
flowchart TD
    A[Development Instance] -->|Create and capture changes in Update Set| B[Update Set in Progress]
    B -->|Set to Complete| C[Completed Update Set]
    C -->|Export as XML| D[XML File]
    D -->|Import into Test Instance| E[Test Instance Update Set]
    E -->|Resolve conflicts| F[Resolved Update Set]
    F -->|Commit to Test| G[Tested and Verified]
    G -->|Export from Test| H[XML File for Production]
    H -->|Import into Production| I[Production Instance Update Set]
    I -->|Resolve conflicts| J[Resolved for Production]
    J -->|Commit to Production| K[Live in Production]
```

## Common misconceptions

- **Misconception:** An update set is the same thing as an application in ServiceNow. **Reality:** An update set is a container for changes made to a single instance, while an application is a collection of related configuration items that can be migrated as a unit using Application Migration. (Both concepts involve moving changes, so beginners conflate them. The exam specifically distinguishes them, and confusing them leads to choosing the wrong migration method.)
- **Misconception:** Once you commit an update set, you can easily roll it back using the update set itself. **Reality:** Committing an update set is permanent. There is no 'rollback' button on a committed update set. To undo the change, you must create a new update set that reverses the original change. (Newcomers expect an undo feature because most software has one. ServiceNow does not, because tracked changes are the source of truth and are not meant to be deleted.)
- **Misconception:** You should test and commit update sets in the development instance before moving them anywhere else. **Reality:** You never commit an update set in the development instance. You mark it as Complete and export it. Committing only happens in the target environment (test or production). (The word 'commit' sounds like 'finish', so beginners think it happens where the work was done. But in ServiceNow, commit means 'permanently apply to this environment', which defeats the purpose of having separate environments.)
- **Misconception:** If I do not set an update set as current, my changes will still be saved somewhere and can be exported later. **Reality:** If you do not set an update set as current before making changes, those changes go into the 'Default' update set. The Default update set cannot be exported cleanly. You should always create and set a named update set before making any changes. (Developers are used to autosave features. They assume anything they do is saved and accessible. In ServiceNow, tracking is opt-in via the current update set assignment.)
- **Misconception:** Update sets are only used in production environments. **Reality:** Update sets are created and used in development environments to capture changes. They are then exported and imported into test and production environments. The source is always a non-production instance. (Beginners hear 'update set' and think it is something applied to the live system. The opposite is true: update sets originate in development.)

## Key takeaways

- An update set is a container that captures all configuration changes made in a ServiceNow instance between when you set it as current and when you mark it Complete.
- The standard migration path for updates is Development -> Test -> Production, and you must never commit directly to production without testing first.
- Conflict resolution is a manual process where an administrator reviews conflicting changes and selects which version to keep before committing.
- Application Migration is the newer, preferred method for moving large applications, while update sets are best for smaller, discrete changes.
- You must always set an update set as 'Current' before making changes, or the changes will be lost in the Default update set which cannot be exported.
- Once an update set is committed, there is no built-in rollback feature; you must create a new update set to reverse the changes.

## FAQ

**What happens if I forget to set an update set as current before making changes?**

Your changes will be saved in the 'Default' update set. The Default update set is not exportable or manageable, so you effectively lose the ability to move those changes to another instance cleanly. You would need to manually redo the work in a properly named update set.

**Can I undo a committed update set?**

No. Once an update set is committed, there is no rollback button. You must create a new update set that reverses the original change, then commit that new update set. This is why testing in a non-production environment is critical.

**What is the difference between an update set and an application in ServiceNow?**

An update set is a simple container for changes to a single instance. An application is a structured collection of related configuration items that can be migrated using Application Migration, which is more automated and suited for complex, multi-scope projects.

**When should I use Application Migration instead of update sets?**

Use Application Migration when you are dealing with large applications that span multiple scopes (like a custom app built in App Engine Studio). Use update sets for smaller changes, like adding a single field or editing a business rule.

**What does 'conflict' mean in the context of update sets?**

A conflict occurs when the update set you are importing contains a change to an element that has already been modified in the target environment by another update set. ServiceNow cannot automatically decide which version is correct, so it flags the conflict and requires manual resolution.

**Can I export an update set that is still 'In Progress'?**

No. An update set must be marked as 'Complete' before it can be exported. The 'Complete' state locks the update set, ensuring that no further changes can be added before it is moved to another environment.

## Check your understanding

1. **What must you do to an update set before you can export it to another instance?**

   Answer: You must change its state to 'Complete'. The Complete state locks the update set and makes it available for export as an XML file.

2. **What happens when you commit an update set in a target environment?**

   Answer: All changes contained in the update set are permanently applied to that environment. There is no built-in rollback mechanism; you must create a new update set to reverse the changes.

3. **Why should you never commit an update set directly in a development instance?**

   Answer: Development instances are for building and capturing changes, not for permanently applying them. Committing in development would make the changes permanent there and defeat the purpose of moving them through test and production stages.

4. **How does ServiceNow handle a conflict when you import an update set?**

   Answer: ServiceNow detects that the target instance already has a different version of an element that the update set modifies. It flags each conflict and requires a human administrator to manually resolve the conflict by choosing which version to keep before committing.

5. **What is the primary advantage of Application Migration over traditional update sets?**

   Answer: Application Migration uses the Application Repository to automate the transfer of entire applications between instances, making it more suitable for large, multi-scope projects and reducing manual export/import steps.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-csa/updates-and-release-management