System update sets

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of System update sets

    System update sets in ServiceNow enable administrators and developers to group configuration changes into a named set that can be moved between instances for testing or deployment. This facilitates promoting new functionality developed in non-production instances to other environments efficiently.

    Show full answer Show less

    An update set is essentially an XML file containing unique identifiers, a list of configuration changes, and a state indicating whether it can be retrieved and applied by another instance. Update sets track changes to both applications and system platform features.

    Important Considerations

    • Update sets can be moved across instances running different ServiceNow family release versions, but compatibility issues may arise, especially when moving updates from newer to older releases. Such cases require careful testing to avoid potential outages or data loss.
    • Similar version constraints apply when moving updates between instances running different versions of ServiceNow Store applications.
    • Backing out an update set triggers an out-of-the-box business rule that deletes related sysupgradestate records; this is expected behavior.

    System Properties Management

    Administrators can keep system properties private to exclude them from update sets. This prevents overwriting critical instance-specific settings, such as production properties being replaced by development values.

    Application Developer Controls

    • Developers can create update sets targeted to specific application versions.
    • They can specify which application tables are tracked in update sets to fine-tune change management.

    Update Set Data Structure and Management

    • Update sets are stored in the Update Set [sysupdateset] table.
    • Each configuration change is recorded in the Customer Update [sysupdatexml] table linked to the update set.
    • Application file properties are transferred along with customized objects in single update records.
    • Version history of changes is maintained in the Versions [sysupdateversion] table, allowing administrators to compare and revert specific object versions.
    • Administrators can suppress version tracking for specific tables and exclude certain fields from updates to avoid skipping entire records.
    • Direct modification of Customer Update [sysupdatexml] records is not recommended.

    What This Enables for ServiceNow Customers

    By leveraging system update sets, ServiceNow customers can efficiently manage and migrate configuration changes across instances while maintaining control over version compatibility and sensitive system properties. The structured tracking and versioning capabilities help ensure consistency, facilitate rollback if needed, and support application lifecycle management in complex environments.

    An update set is a group of configuration changes that can be moved from one instance to another. This feature allows administrators to group a series of changes into a named set and then move them as a unit to other systems for testing or deployment.

    Note:
    When an update set is backed out, there is an OOB business rule that will delete sys_upgrade_state record on customer update deletion. This is an expected behavior.

    An update set is an XML file that contains:

    • A set of record details that uniquely identify the update set.
    • A list of configuration changes.
    • A state that determines whether another instance can retrieve and apply configuration changes.
    Update sets track changes to applications and system platform features. This allows developers to create new functionality on a non-production instance and promote the changes to another instance.
    Warning:
    Update sets allow moving changes between instances that may be running different family release versions and different features. You can always load an update set created on an older family release on an instance running a newer family release. Loading an update set created on a newer family release on an instance running an older family release requires additional testing to determine compatibility. Updates from newer family releases may not produce the same functionality when moved to older family releases. In extreme cases, newer family release updates may cause outages or data loss on an older family release instance. Where possible, avoid moving updates from newer family releases to older family releases. Similar constraints apply to moving updates between instances running different versions of ServiceNow Store apps.

    System properties

    Administrators can exclude system properties from update sets by making them private. Keeping system properties private prevents settings in one instance from overwriting values in another instance. For example, you may not want a system property in a production instance to use a particular value from a development instance. See Add a system property.

    Applications

    Application developers have additional options with update sets such as:

    • Create an update set for a specific version of an application.
    • Specify which application tables to track in update sets.

    Update set tables

    Each update set is stored in the Update Set [sys_update_set] table, and the customizations that are associated with the update set, which are entries in the Customer Update [sys_update_xml] table, appear as a related list on the update set record.

    When a tracked object is customized, a corresponding record is added or updated in the Customer Update [sys_update_xml] table and is associated with the user current update set. The associated application file properties are tracked and transferred along with the customized object in a single update record. A corresponding record is also added to the Versions [sys_update_version] table.

    The Customer Update table contains one record per customized object, per update set. The Versions table contains one record per change to a customized object.
    • Administrators can compare two versions and revert to a specific version of an object.
    • Administrators can suppress versions for specific tables.
    • Administrators can specify fields on tracked tables that you can change without skipping updates to the rest of the record (exclude the field from the update).
    Note:
    Do not directly modify Customer Updates [sys_update_xml] records.