Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • Now Platform App Engine
Table of Contents
Choose your release version
    Home Orlando Now Platform App Engine Now Platform App Engine Application tools System update sets Get started with update sets

    Get started with update sets

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Get started with update sets

    Because update sets make changes to an instance, review this information to avoid errors and performance issues. Learn how to plan the update process and avoid common mistakes.

    When to use update sets

    Deployment option Good for Future considerations
    Update Sets Storing changes to a baseline or installed application.

    Storing and applying a particular version of an application.

    Producing a file for export.

    You can manually create update sets to store a particular application version.

    Use update sets to deploy patches or changes to installed applications.

    Note: Do not use update sets to install applications. Instead, use the application repository or the ServiceNow Store to install applications.
    Application Repository Installing and updating applications on all company instances.

    Automatically managing application update sets.

    Restricting access to applications to the same company.

    Deploying completed applications to end users.

    Consider uploading an application to the ServiceNow Store to share it with other users.

    Allows installation of and update to the latest application version only.

    Use update sets to store prior application versions.

    Note: If used with team development, publish applications only from a parent instance.
    Team Development Providing change management across multiple instances.

    Allowing multiple developers to work on applications.

    Organizations that have access to several non-production instances.

    Consider providing each development team access to a dedicated development instance.

    Requires developers to manually merge colliding changes.

    Works only for instances owned by the same organization.

    Note: If used with the application repository, publish applications from a parent instance.

    Plan the update process

    Before working with update sets, create a standard process for moving customizations from instance to instance using this check list:
    1. Check that both instances are on the same version. Customizations may not work if they rely on code that has changed between versions.
    2. Determine the changes to make in a single update set. Complete your update sets as you finish small to medium-sized tasks. As update sets get larger, it becomes harder to review them, takes longer to identify specific changes within them, increases the risk of conflicts with other update sets, and takes more time to preview and commit them. This is especially true if the update sets contain schema changes or revisions to large workflows or if the set has to be backed out.
    3. Ensure that all base system records have matching sys_id fields. Some base system records are created on an instance after provisioning and do not match between different instances, leading to problems with update sets. The best way to avoid this issue is to:
      • Provision production and non-production instances.
      • Clone the production instance onto the non-production instance.
    4. Identify a common path for update sets to move from instance to instance and maintain that model. Never migrate the same update set from multiple sources. Move update sets from dev to test and then from test to production.
    5. Plan for when to commit the update sets to production. Avoid committing an update sets to a production instance during business hours. The instance may perform slower temporarily as the update sets applies.
    6. Make sure update set names are clear. Create a naming convention to coordinate changes from multiple developers and to reference when committing the changes to another instance.
      • If update sets are being generated as fixes for problems, consider including the problem ticket in the name (for example, PR10005 - Duplicate Email Issues Fix).
      • If you need more than one update set to address a problem, include a sequence number in the naming convention so that update sets are applied in the order that they were created (for example, PR10005 - Duplicate Email Issues Fix and PR10005.2 - Duplicate Email Issues Fix).
    7. Understand the following about update sets:
      • What records are generated.
      • Which customizations are tracked.
      • Which dictionary changes are valid .
      • Which customizations can be backed out (reversed) once applied.
    8. Before making any customizations, double-check that the correct update set is selected.

    Working with update sets

    Review this information to avoid errors and performance issues.
    • Do not delete update sets. If an update set is deleted, any updated records may be overwritten in the next update.
    • Do not include the system_id field from the ldap_server_config record in an update set. An update set from a working configuration points to the wrong system_id node for the target instance and does not work.
    • Do not back out the Default update set. This action causes damage to the system.
    • Never change the Update Set field value (update_set) in a Customer Update record (sys_update_xml). If a customization is made in the wrong update set, take the following action:
      1. Switch to the desired update set.
      2. Modify the object (record) that was originally changed. You can make a trivial change, such as adding a field.
      3. Save the record.
      4. Back out the change just performed, and then save the record again.

        This action ensures that the latest version of the object is included in the desired update set and prevents duplicate updates for the same object in a single update set.

    • Do not mark an update set as Complete until it is ready to migrate. Once an update set is complete, do not change it back to In progress. Instead, create another update set for the rest of the changes, and make sure to commit them together in the order that they were created. Naming conventions may help in this case (for example, Performance Enhancements and Performance Enhancements 2).
    • Do not manually merge updates into an update set. Always use the Merge Update Sets module. This tool compares duplicate files between update set and selects the newest version.
    • If a committed update set has a problem in the test instance, build the fix in another update set in the development instance. Commit this set to the test instance, and then make sure both sets are migrated to the production instance and committed in the order they were made.
    • Always preview an update set before committing it.
    • Set completed update set on the production instance to Ignore. This state ensures the update set is not reapplied when cloning the instance.
    • Keep a to-do list of manual changes and data loads that need to be completed after an update set is applied.
    • Do not make too many changes at one time. Verify that the correct changes have been made incrementally.

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Get started with update sets

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Get started with update sets

      Because update sets make changes to an instance, review this information to avoid errors and performance issues. Learn how to plan the update process and avoid common mistakes.

      When to use update sets

      Deployment option Good for Future considerations
      Update Sets Storing changes to a baseline or installed application.

      Storing and applying a particular version of an application.

      Producing a file for export.

      You can manually create update sets to store a particular application version.

      Use update sets to deploy patches or changes to installed applications.

      Note: Do not use update sets to install applications. Instead, use the application repository or the ServiceNow Store to install applications.
      Application Repository Installing and updating applications on all company instances.

      Automatically managing application update sets.

      Restricting access to applications to the same company.

      Deploying completed applications to end users.

      Consider uploading an application to the ServiceNow Store to share it with other users.

      Allows installation of and update to the latest application version only.

      Use update sets to store prior application versions.

      Note: If used with team development, publish applications only from a parent instance.
      Team Development Providing change management across multiple instances.

      Allowing multiple developers to work on applications.

      Organizations that have access to several non-production instances.

      Consider providing each development team access to a dedicated development instance.

      Requires developers to manually merge colliding changes.

      Works only for instances owned by the same organization.

      Note: If used with the application repository, publish applications from a parent instance.

      Plan the update process

      Before working with update sets, create a standard process for moving customizations from instance to instance using this check list:
      1. Check that both instances are on the same version. Customizations may not work if they rely on code that has changed between versions.
      2. Determine the changes to make in a single update set. Complete your update sets as you finish small to medium-sized tasks. As update sets get larger, it becomes harder to review them, takes longer to identify specific changes within them, increases the risk of conflicts with other update sets, and takes more time to preview and commit them. This is especially true if the update sets contain schema changes or revisions to large workflows or if the set has to be backed out.
      3. Ensure that all base system records have matching sys_id fields. Some base system records are created on an instance after provisioning and do not match between different instances, leading to problems with update sets. The best way to avoid this issue is to:
        • Provision production and non-production instances.
        • Clone the production instance onto the non-production instance.
      4. Identify a common path for update sets to move from instance to instance and maintain that model. Never migrate the same update set from multiple sources. Move update sets from dev to test and then from test to production.
      5. Plan for when to commit the update sets to production. Avoid committing an update sets to a production instance during business hours. The instance may perform slower temporarily as the update sets applies.
      6. Make sure update set names are clear. Create a naming convention to coordinate changes from multiple developers and to reference when committing the changes to another instance.
        • If update sets are being generated as fixes for problems, consider including the problem ticket in the name (for example, PR10005 - Duplicate Email Issues Fix).
        • If you need more than one update set to address a problem, include a sequence number in the naming convention so that update sets are applied in the order that they were created (for example, PR10005 - Duplicate Email Issues Fix and PR10005.2 - Duplicate Email Issues Fix).
      7. Understand the following about update sets:
        • What records are generated.
        • Which customizations are tracked.
        • Which dictionary changes are valid .
        • Which customizations can be backed out (reversed) once applied.
      8. Before making any customizations, double-check that the correct update set is selected.

      Working with update sets

      Review this information to avoid errors and performance issues.
      • Do not delete update sets. If an update set is deleted, any updated records may be overwritten in the next update.
      • Do not include the system_id field from the ldap_server_config record in an update set. An update set from a working configuration points to the wrong system_id node for the target instance and does not work.
      • Do not back out the Default update set. This action causes damage to the system.
      • Never change the Update Set field value (update_set) in a Customer Update record (sys_update_xml). If a customization is made in the wrong update set, take the following action:
        1. Switch to the desired update set.
        2. Modify the object (record) that was originally changed. You can make a trivial change, such as adding a field.
        3. Save the record.
        4. Back out the change just performed, and then save the record again.

          This action ensures that the latest version of the object is included in the desired update set and prevents duplicate updates for the same object in a single update set.

      • Do not mark an update set as Complete until it is ready to migrate. Once an update set is complete, do not change it back to In progress. Instead, create another update set for the rest of the changes, and make sure to commit them together in the order that they were created. Naming conventions may help in this case (for example, Performance Enhancements and Performance Enhancements 2).
      • Do not manually merge updates into an update set. Always use the Merge Update Sets module. This tool compares duplicate files between update set and selects the newest version.
      • If a committed update set has a problem in the test instance, build the fix in another update set in the development instance. Commit this set to the test instance, and then make sure both sets are migrated to the production instance and committed in the order they were made.
      • Always preview an update set before committing it.
      • Set completed update set on the production instance to Ignore. This state ensures the update set is not reapplied when cloning the instance.
      • Keep a to-do list of manual changes and data loads that need to be completed after an update set is applied.
      • Do not make too many changes at one time. Verify that the correct changes have been made incrementally.

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login