--- sourceDocument: Zurich ServiceNow AI Platform Administration sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/platform-administration Release : - zurich ft:locale : - en-US ft:publication_title : - Zurich ServiceNow AI Platform Administration ft:clusterId : - platadm bundleId : - platadm workflow : - Platform --- # skipped records # Skipped records that occur during application installation {#ariaid-title1} * Release version: Zurich * * Updated July 31, 2025 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Skipped records that occur during application installation When deploying or upgrading global or scoped applications in ServiceNow, some records may be skipped. These skipped records occur either due to local metadata updates on the target instance or when applying update sets. The occurrence of skipped records depends on the deployment model and configuration properties, and they are logged in thesysupgradehistorylog. Understanding how skipped records behave helps ServiceNow customers manage application installations and updates more effectively. Show full answer Show less ## Deployment Use Cases The behavior of skipped records varies by deployment type and application type as follows: * **Source Control (Scoped \& Global):** No records are skipped; the application loads directly. If there are local update XML files, users are prompted to stash those changes. * **App Repository (Scoped):** Skipped records are generated to preserve customizations. * **App Repository (Global):** Application changes apply normally; skipped records occur only when a superior claim conflict is detected. * **Store (Scoped):** Skipped records are generated; customization changes are applied. * **Source Control Customization:** No skips; customization loads from Source Control with prompts to stash local changes if present. * **App Repository Customization:** No skipped records; customization changes apply. * **Store or App Repository for Scoped and Customization:** No skips unless the customization updates the base application record, which then creates a skipped update log entry. ## Author Elective Updates The **authorelectiveupdate** folder contains deleted metadata elements (such as schema changes or choice set unloads) that are packaged but not applied by default during application installation. These elements can be applied based on specific system property settings. Key properties controlling these updates include: * **com.glide.apps.includeonlysyschoice:** Loads only deleted elements and syschoice updates from authorelectiveupdate. Default: False. * **com.glide.apps.includemyschema:** Loads deleted schema elements from authorelectiveupdate for customer applications (not third-party). Default: False, but new instances since Orlando default to True. * **com.glide.apps.forceskips:** Forces creation of skipped records for all authorelectiveupdate elements. Default: False. * **com.glide.apps.includemydeletes:** Processes authorelectiveupdate for scoped apps. Default: False. * **com.glide.apps.includeglobaldeletes:** Processes authorelectiveupdate for global apps. Default: False. ## Claims and Skipped Records Claims apply mainly to global applications and customizations. They help determine which record to apply when multiple applications include the same file. If a superior claim exists, skipped records are logged to indicate conflicts. Customers can review these skipped record logs to understand and resolve conflicts during upgrades. Some records may be skipped when you make local updates to global or scoped applications. Skipped records can occur either when you modify the metadata records in the instance to which you're deploying or when you apply an update set. Depending on the deployment model you use and the state of applicable properties, you may risk "skipped records," which are generated in the sys_upgrade_history_log. Learn what to expect on your instance when you upgrade an application using various different methods. ## General use cases {#generation-skip-records-app-installs__section_xgl_k2w_rnb} Under most circumstances, these general use cases occur during application installation: {#generation-skip-records-app-installs__table_fmj_n2w_rnb__entry__3} | Deployment type | Application type | Expected outcome | |-|-|-| | Source Control | Scoped | No skips, application loads from Source Control. If local update xml exists, you are prompted to stash those changes. | | Source Control | Global | No skips, application loads from Source Control. If local update xml exists, you are prompted to stash those changes. | | App Repository | Scoped | Skipped records are generated and customizations preserved. | | App Repository | Global | Application changes applied and skipped records are generated only when a superior claim is found. For details, see [Review skipped records using related lists](https://www.servicenow.com/docs/dLsrmT8jRzGA~krYvdK2Lg#uc-access-rl "Use different related lists to resolve, track and review the skipped records in an upgrade."). | | Store | Scoped | Skipped records are generated, customization changes applied. | | Source Control | Customization | No skips, customization loads from Source Control. If local update xml exists, you are prompted to stash those changes. | | App Repository | Customization | No skipped records are generated, customization changes applied. | | Store/App Repository | Scoped and Customization | No skipped records are generated unless the customization updates the base application record. In this case, a log entry of a skipped update for the base application is created. | [ ] {#generation-skip-records-app-installs__table_fmj_n2w_rnb} ## Author Elective Updates {#generation-skip-records-app-installs__section_mh3_gfw_rnb} It's important to understand the purpose of the author_elective_update folder. When ServiceNow packages your application for the repository or for committing to Source Control, additional elements (which might have been previously ignored), are unloaded to the author_elective_update folder. (These deleted elements are often referred to simply as "deletes.") When your application is installed on your own instance, the deleted files are automatically loaded from the author_elective_update folder. For example, if you changed the schema of your application by deleting a table or a column, those files are tracked in the folder but are not applied by default. There are specific rules that apply to author elective updates that you can change, based on the properties you can set. This folder contains metadata deleted files, including schema changes, and choice set unloads that you can apply or ignore. Whether you apply or ignore them, and whether corresponding skipped records are generated, depends on the state of the following properties and processing flow: {#generation-skip-records-app-installs__table_dcf_jfw_rnb__entry__4} | Property name | Behavior | Default | Used in Source Control | |-|-|-|-| | com.glide.apps.include_only_sys_choice | Loads only deleted elements and updates to sys_choice fields from author_elective_update | False | No | | com.glide.apps.include_my_schema | Loads only deleted elements to schema files from author_elective_update. Applies to customer application installations and not third-party apps. | False | No | | com.glide.apps.force_skips | Creates skipped records for all of author_elective_update | False | No | | com.glide.apps.include_my_deletes | Process author_elective_update | False | Yes | | com.glide.apps.include_global_deletes | Process author_elective_update for global applications | False | Yes | [ ] {#generation-skip-records-app-installs__table_dcf_jfw_rnb} Note: When there is no property for com.glide.apps.include_my_schema, it defaults to False. However, since the Orlando release, new instances have a default entry in the table to set it as True. ## Claims {#generation-skip-records-app-installs__section_uhm_xfq_snb} Claims apply to global applications and application-customizations. In global applications, claims allow the system to choose a record deterministically should the same file be included in multiple applications. If you see a superior claim, an upgrade history log for the skipped record is created to identify a conflicting claim status. For details, see [Review skipped records using related lists](https://www.servicenow.com/docs/dLsrmT8jRzGA~krYvdK2Lg#uc-access-rl "Use different related lists to resolve, track and review the skipped records in an upgrade.").