Update Set Management and Best Practices

Update Set Management and Best Practices – ServiceNow CAD Guide

Introduction to Update Set Management

Update Set Management is a critical concept in the ServiceNow Certified Application Developer (CAD) exam. It governs how customizations and configurations are tracked, organized, transported, and deployed across ServiceNow instances. Mastering this topic is essential not only for passing the exam but also for real-world ServiceNow development.

Why Is Update Set Management Important?

In any enterprise ServiceNow environment, there are typically multiple instances: Development (Dev), Test/QA, and Production (Prod). Changes made in one instance need to be reliably moved to other instances without introducing errors, conflicts, or data loss. Update Sets are ServiceNow's native mechanism for achieving this.

Without proper Update Set Management:
- Changes can be lost or overwritten
- Conflicts between developers' work can go undetected
- Production environments can become unstable
- Rollback of changes becomes extremely difficult
- Audit and compliance tracking becomes impossible

Proper Update Set Management ensures traceability, reliability, and control over the application lifecycle.

What Is an Update Set?

An Update Set is a group of customizations (configuration changes) that can be moved from one ServiceNow instance to another. When you make changes to the system — such as creating or modifying Business Rules, Client Scripts, UI Policies, Script Includes, or other application artifacts — those changes are captured in the currently selected Update Set.

Key characteristics of Update Sets:
- They capture customizations, not data (e.g., incident records are not captured)
- Each change creates a Customer Update (sys_update_xml) record within the Update Set
- Only one Update Set can be active (current) per user at a time
- The Default Update Set is always available and captures changes if no other Update Set is selected
- Update Sets are scoped to a specific application scope

How Update Sets Work – The Complete Lifecycle

1. Creation: A developer creates a new Update Set in the Dev instance (System Update Sets > Local Update Sets > New). They give it a descriptive name and optionally assign it to a parent Update Set (batch).

2. Selection: The developer sets the new Update Set as their current Update Set using the Update Set picker in the upper-right corner of the ServiceNow interface or via the system settings.

3. Development: As the developer makes changes (e.g., modifying a Business Rule, creating a UI Policy), each change is automatically recorded as a Customer Update record inside the current Update Set.

4. Completion: When development is finished, the Update Set state is changed from In Progress to Complete. Once completed, no further changes are captured in that Update Set. The state can be reverted to In Progress if additional changes are needed.

5. Export/Retrieval: The completed Update Set is moved to the target instance. This can be done by:
- Retrieving the Update Set from the target instance (if instances are connected) via System Update Sets > Update Sources
- Exporting the Update Set as an XML file and importing it into the target instance (for disconnected instances)

6. Preview: On the target instance, the retrieved Update Set appears as a Remote Update Set. The administrator runs a Preview to detect any potential conflicts or issues before committing.

7. Conflict Resolution: If the Preview identifies conflicts (e.g., the same record was modified in both source and target instances), they must be resolved. Options include:
- Accept remote update – overwrite the target with the incoming change
- Skip remote update – keep the existing target version

8. Commit: Once all conflicts are resolved, the Update Set is committed, applying all changes to the target instance. This action is not easily reversible.

Types of Update Sets

- Local Update Sets: Created and managed on the current instance. Changes are captured here during development.
- Remote Update Sets: Update Sets retrieved from another instance. They appear on the target instance and must be previewed and committed.
- Batch Update Sets (Parent Update Sets): A mechanism to group multiple related Update Sets together. Child Update Sets are assigned a parent, and when the parent is retrieved/committed, all children are processed together. This helps manage complex deployments with multiple related changes.

Key Concepts and Details

Default Update Set: Every instance has a Default Update Set. If a developer does not explicitly select an Update Set, their changes go into the Default Update Set. Best practice is to avoid using the Default Update Set because it makes tracking and transporting changes difficult.

Application Scope and Update Sets: Update Sets are scoped to a specific application. When working in a scoped application, changes are captured in an Update Set within that scope. The Update Set picker shows Update Sets for the current application scope.

What Gets Captured: Update Sets capture changes to configuration records such as:
- Business Rules, Client Scripts, UI Policies, UI Actions
- Script Includes, Scheduled Jobs
- Forms, Lists, and related layout changes
- ACLs, Roles
- Workflow and Flow Designer configurations
- Table definitions and dictionary changes
- System Properties (when configured to be captured)

What Does NOT Get Captured:
- Data records (incidents, users, CMDB records, etc.)
- Some system-level settings
- Attachments (unless specifically configured)
- Homepage and dashboard configurations (partially)
- Certain scheduled job execution data

Backing Out Changes: ServiceNow provides a Back Out feature for committed Update Sets, but it has limitations. It creates a new Update Set that reverses the changes, but it may not perfectly restore the previous state, especially if other changes have been made since the commit. This is why thorough Preview and testing are essential.

Update Set Best Practices

These best practices are frequently tested on the CAD exam:

1. Never use the Default Update Set for intentional development. Always create a named Update Set with a clear, descriptive name that identifies the feature, story, or defect being addressed.

2. Use a consistent naming convention. Example: STRY001234 - Add validation to Incident form. Include ticket numbers, descriptions, and optionally dates or developer initials.

3. Keep Update Sets small and focused. Each Update Set should represent a single logical unit of work (one feature, one fix). This makes troubleshooting, previewing, and backing out much easier.

4. Complete Update Sets promptly. Don't leave Update Sets in the In Progress state for extended periods. This reduces the risk of accidentally capturing unrelated changes.

5. Always Preview before Committing. Never skip the Preview step. Review all conflicts carefully and resolve them appropriately before committing.

6. Test in a sub-production environment before promoting to Production. Follow the standard promotion path: Dev → Test/QA → Prod.

7. Use Batch (Parent) Update Sets when multiple related Update Sets need to be deployed together to ensure consistency.

8. Avoid circular or cross-referencing changes between Update Sets when possible, as this creates deployment dependencies.

9. Document your Update Sets. Use the Description field to clearly explain what changes are included and any dependencies or prerequisites.

10. Be cautious with Update Sets that modify shared resources (e.g., global Business Rules, shared Script Includes) as they may impact other teams or applications.

11. Review Customer Updates within an Update Set before completing it. Remove any accidental or unnecessary changes to keep the Update Set clean.

12. Consider using Application Repository (source control) for scoped applications as a more modern alternative or complement to Update Sets, especially for team-based development.

Collision and Conflict Detection

During Preview, ServiceNow compares each incoming Customer Update with the existing records on the target instance. Conflicts arise when:
- The same record exists on the target and has been modified independently
- A record referenced by the Update Set doesn't exist on the target (missing dependency)
- The incoming change would overwrite a newer version on the target

Understanding how to interpret and resolve these conflicts is essential for the exam.

Update Sets vs. Other Transport Mechanisms

It's important to understand when to use Update Sets versus other mechanisms:
- Update Sets: Best for configuration changes, traditional development workflows
- Application Repository / Source Control: Best for scoped application development, team collaboration, version control
- Plugins: Installed via the Plugin Manager; not transported via Update Sets
- Data Export/Import: For moving data records (not configurations)

---

Exam Tips: Answering Questions on Update Set Management and Best Practices

1. Know the lifecycle thoroughly: Create → Select → Develop → Complete → Retrieve/Export → Preview → Resolve Conflicts → Commit. Many questions will test your understanding of this sequence and what happens at each stage.

2. Default Update Set questions are common. Remember: the Default Update Set should not be used for planned development. Changes captured there are hard to transport cleanly. If a question asks about best practices, selecting the Default Update Set is almost always the wrong answer.

3. Understand what is and isn't captured. If a question asks about moving data records between instances, Update Sets are NOT the answer. Update Sets capture configuration, not data.

4. Preview before Commit is mandatory best practice. Any answer that suggests committing without previewing is incorrect.

5. Conflict resolution questions: Know the difference between accepting a remote update and skipping it. Understand that accepting the remote update overwrites the local version, while skipping preserves the local version.

6. Batch Update Sets: Expect questions about grouping related Update Sets. The correct approach is to use a Parent Update Set (batch) to combine related child Update Sets for deployment.

7. Back Out limitations: If a question asks about reverting committed changes, remember that the Back Out feature exists but has limitations. It's not a guaranteed perfect rollback.

8. Scope awareness: Update Sets are tied to an application scope. If a question involves scoped applications, the developer must be in the correct scope to capture changes in the appropriate Update Set.

9. Watch for distractor answers that mention using Update Sets to move data, skip the Preview step for efficiency, or use one large Update Set for all changes. These are typically incorrect.

10. Elimination strategy: On scenario-based questions, eliminate answers that violate best practices (e.g., developing directly in Production, using Default Update Set, committing without preview). The remaining answer is likely correct.

11. Remember the states: Update Sets have states – In Progress, Complete, and on the remote side, Loaded, Previewed, and Committed. Questions may test your knowledge of these states and valid transitions.

12. Practice scenario questions: The exam often presents real-world scenarios (e.g., 'A developer needs to move a Business Rule from Dev to Prod. What is the correct sequence of steps?'). Walk through the lifecycle mentally to identify the right answer.

By thoroughly understanding the mechanics of Update Sets and consistently applying best practices, you will be well-prepared to answer any CAD exam question on this topic with confidence.