Update Sets are one of the most widely used deployment mechanisms in ServiceNow. However, a very common — and risky — practice still exists in many projects: adding data records to Update Sets using the “Add to Update Set” UI Action.
This article explains why adding records to Update Sets is not recommended, what can happen during a rollback, and which safer alternatives should be used instead.
The Core Problem
Many users use the “Add to Update Set” UI Action (related link) to capture records (not configuration) and move them between environments.
At first, this seems convenient.
In reality, it introduces a high risk of data loss, especially when rollbacks are involved.
What Happens During a Rollback
When an Update Set that contains records is rolled back, ServiceNow attempts to reverse what was deployed.
The consequence:
- Records added via Update Set can be deleted from the target environment
- References associated with those records can also be lost (if the reference cascade not configured correctly)
- The rollback does not restore the previous data state
- There is no automatic recovery of deleted records (if the table is not audit)
Why Update Sets Are the Wrong Tool for Data/Records
Update Sets are designed for configuration, such as:
- Application metadata
- Dictionary changes
- Scripts, rules, and UI elements
- Structural platform components
They are not designed for:
- Business data
- Transactional records
- Reference data
Using Update Sets to move records creates a fragile deployment model that breaks easily during rollback scenarios.
The Risk of “Add to Update Set”
The “Add to Update Set” UI Action makes it technically possible to capture records — but possible does not mean safe or supported.
Common risks include:
- Accidental deletion of records after rollback
- Inconsistent data between environments
- Broken references
- False sense of recoverability
Recommended Best Practices
✅ Use Update Sets only for configuration
Never include records that represent data.
✅ Avoid the “Add to Update Set” UI Action for records
Even though it exists, it should not be used for data migration.
✅ Use proper data migration strategies instead, such as:
- Import Sets
- Data sources
- XML
