Do not combine the usage of both Update Sets and the Application Repository for scoped app development. This will result in numerous issues, including skipped changes, commit errors, and more. Once you have installed an application from the Application Repository, you must continue to develop and publish to the Application Repository for all future development. If you decide to develop an application using update sets, you must continue to use that method exclusively.

Release or Environment



Although difficult, you can work your way back to using the Application Repository for development if you have mistakenly committed update sets for a scoped app and wish to go back to using the previous method.

NOTE: This method will not work if you have never used the Application Repository for your app. If the application was originally installed via update set, the only way to switch is to completely delete the app and perform a fresh install from the Application Repository.

The solution is to revert the entire application to its base system version from the application repository. Doing so requires some special steps to prevent all of the previously-committed update sets from causing conflicts:

  1. Publish the application to the Application Repository on the development instance. This will package and publish the most current version of the application to the repo, ready to install on the target instance.
  2. On the target instance, you must set the replace_on_upgrade field to true on all sys_update_xml records for the application. This will prevent these updates from causing conflicts when you install the application from the Application Repository. This step is best performed via script. An example of such a script can be found below.
  3. Once all sys_update_xml records for the app have been updated, install the latest version of your application on the instance. If executed properly, this will apply the base system version of each application file in the app.

What follows is an example of a script that can be used to set replace_on_upgrade to true on every existing sys_update_xml record for the specified application. NOTE: This script is only provided as an example. Usage of this script is done at your own risk. Modification of this script can result in irreversible corruption of sys_update_xml data.

preventConflicts('12345678ABCDEFGH12345678ABCDEFGH'); // Sys ID of your app's sys_store_app record
function preventConflicts(appid) {
    var gr = new GlideRecord('sys_update_xml');
    gr.addQuery('application', appid);
    while( {
        gr.replace_on_upgrade = true;

Article Information

Last Updated:2019-09-19 17:37:39