Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Getting started with update sets

Log in to subscribe to topics and get notified when content changes.

Getting started with update sets

Before working with update sets, create a standard process for moving customizations from instance to instance. When working with update sets, be sure to avoid common pitfalls.

For example, an update set called Incident Management 2.0 might hold a set of enhancements to incident management. While Incident Management 2.0 is marked as the current update set, all changes are tracked in it.

An update set consists of:
  • 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.
By default, update sets only track changes to baseline applications and platform features. This allows developers to create functionality on a sub-production instance and promote the changes to another instance.
Administrators have the following options with update sets.
  • Create an update set to store local changes.
  • Select the current update set to store local changes.
  • Commit an update set to prepare it for distribution.
  • Report on the contents of update sets.
  • Compare update sets to determine what differences they contain.
  • Merge separate update sets into a single update set.
  • Create an external file from an update set.
  • Retrieve update sets from remote instances.
  • Apply retrieved update sets.
  • Back out changes applied from an update set.
Application developers have 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.