🔄 Update Sets in ServiceNow

CASE STUDY 1:🌐 1. What are Update Sets?

Update Sets in ServiceNow are containers that capture configuration changes made in an instance so they can be moved between environments (e.g., from Development → Test → Production).

💡 Key Point: Update Sets do not capture data, only configuration and customization changes.

⚙️ 2. What Do Update Sets Capture?

Update Sets record customizations and configurations, such as:

• Business Rules

• Client Scripts

• UI Policies / UI Actions

• Form layouts and Lists

• Workflows and Flow Designer flows

• Script Includes

• Tables, Fields, and Dictionary changes

• Email Notifications and Templates

🚫 3. What Update Sets Do NOT Capture

Some items are not included in Update Sets and need manual migration or cloning:

• Data (e.g., records in tables like incident)

• Scheduled Jobs

• Users and Groups (sys_user, sys_user_group)

• Instance-specific settings (e.g., System Properties, Integration credentials)

• Attachments and Images

CASE STUDY 2:📥  How Update Sets Work (Step-by-Step)

1. Select Current Update Set

   • In the Developer instance, go to System Update Sets → Local Update Sets.

   • Mark one as current—all changes now get tracked here.

2. Make Changes

   • Any captured changes (e.g., creating a Business Rule) are recorded in the Update Set.

3. Close the Update Set

   • Once work is complete, mark it Complete.

4. Export Update Set (XML)

   • Export the Update Set as an XML file.

5. Import into Target Instance

   • In Test/Prod instance, import the Update Set XML.

6. Preview and Commit

   • Preview: Checks for errors, collisions, and missing dependencies.

   • Commit: Applies changes permanently.

CASE STUDY 3:⚡  Advanced Concepts

1. Update Set Hierarchy

   • Update Sets can be parent-child linked to manage large projects.

2. Collisions

   • Occur when the target instance already has changes to the same object.

   • Must be resolved before committing.

3. Skipped Changes

   • Changes not committed due to conflicts or errors.

   • Can be fixed manually.

4. Batch Update Sets

   • Multiple Update Sets can be committed together for complex projects.

5. Global vs Scoped Apps

   • Update Sets are global, but for Scoped Applications, the Application Repository is recommended for migrations.

⚡ 1. Update Set Architecture and Mechanics

• Sys_update_xml Table

  • Every change captured in an Update Set is stored as an XML record in the sys_update_xml table.

  • This allows migration but also means order of updates matters.

• Record Tracking

  • Update Sets capture insert/update/delete operations of configuration records.

  • Example: If you create and then delete a Business Rule, the deletion is also captured.

• Captured vs. Uncaptured Changes

  • Not everything is tracked. For example, data, users, and groups need other migration methods.

  • Solution: Use Export Sets, IntegrationHub, or Clone for data.

🔍 2. Collisions, Skips, and Conflicts

• Collision Detection

  • When previewing an Update Set, ServiceNow checks if the target instance already has modifications for the same record.

  • Example: A Business Rule modified in both Dev and Prod → collision warning.

• Skipped Changes

  • Some records are skipped due to dependencies or missing references.

  • Example: A UI Action referring to a missing table in target instance.

• Resolution Approaches

  • Manually compare XML versions of skipped/collided records.

  • Use compare to current feature to analyze differences.

  • Document skipped records for manual fixes.

🛠️ 3. Update Set Strategies for Teams

• Master Update Set Approach

  • Developers work in individual update sets.

  • A lead merges them into a Master Update Set before migration.

  • Reduces conflicts and ensures proper sequencing.

• Project-Based Update Sets

  • One Update Set per project or feature → keeps scope clean.

• Small, Frequent Commits

  • Smaller Update Sets = easier to test and rollback if needed.

• Parallel Development Pitfalls

  • If multiple developers modify the same record in different Update Sets, conflicts arise.

  • Solution: Assign record ownership (e.g., only one developer edits a given Business Rule).

⚙️ 4. Update Set Migration Best Practices

1. Move Dev → Test → Prod sequentially (never skip environments).

2. Always Preview before Commit in Test/Prod.

3. Check Dependencies (e.g., a Script Include referenced by a Business Rule should be in the same Update Set).

4. Use Baseline Comparison to confirm only intended changes are included.

5. Keep an Audit Trail: Maintain naming convention like HRSD_PortalChanges_Jan2025.

🔗 5. Update Sets vs. Application Repository

• Update Sets are best for:

  • Global changes, quick fixes, small-scale customizations.

• Application Repository is better for:

  • Scoped applications, modular development, and distribution via Store.

  • Provides versioning, rollback, and dependency management.

💡 Rule of Thumb:

• Use Update Sets for “global” work.

• Use Application Repository for “scoped apps.”

CASE STUDY 4 :🛠️ Real-World Examples

• Migrating Customizations
  A new Change Management workflow created in Dev is exported via Update Set and moved into Prod.

• Team Development
  Each developer uses their own Update Set → merged into a Master Update Set before migration.

• Fix Scripts
  Minor scripts for hotfixes can be tracked in Update Sets and deployed across environments.

💡  Best Practices for Update Sets

• ✅ Always name Update Sets clearly (include project and date).

• ✅ Use a separate Update Set per project or feature.

• ✅ Regularly check the Update Set progress to avoid missed changes.

• ✅ Always Preview before Commit.

• ✅ Document skipped changes and resolve conflicts before committing.

• ✅ For Scoped Applications, prefer Application Repository instead of Update Sets.

🎬 Conclusion

Update Sets are the backbone of configuration migration in ServiceNow.
They allow admins and developers to capture, package, and move customizations safely between instances. With proper governance and best practices, Update Sets ensure smooth, consistent deployments across environments.