---
sourceDocument: Yokohama Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/application-development

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Push a version

# Push a version {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

Pushing promotes changes from the development instance to the parent instance and
commits the current version of a customized record on the development instance as the
current version on the parent instance.

## About this task

Pushing adds only the current development version to the parent, not all the
development versions.  
Note:  
Updates to records from different applications cannot be pushed/pulled in the same push/pull. To resolve the error in the case that updates to other applications are mixed in: De-queue the updates to other applications. Push for one application. Re-queue the updates to one application. Push and then repeat as needed.

Pushing creates a local Update Set on the parent that is marked as complete. Pushed
changes are also tracked as local changes on the parent. Therefore, you can promote
changes through your development and test hierarchy by transferring the Update Set
or by pushing the local changes. Each push is recorded in the Push or Pull table on
the development instance.

## Procedure

1. Navigate to AllTeam DevelopmentTeam Dashboard.
2. [Queue
   the local changes](https://servicenow-prod.fluidtopics.net/L_BB0eW_e4NsLCLlU6o7~Q "Application developers can queue a local change for a push to ensure the changes are available to other developers.") that are ready to push. {#t_PushAVersion__step-2-queue-local-changes}
{#t_PushAVersion__step-2-queue-local-changes}
3. [Pull versions](https://servicenow-prod.fluidtopics.net/diUKUhkwnpFn2Sn5fuSv4A "Pulling retrieves versions of customized records from the parent instance and adds them on the development instance. Pulling does not retrieve any versions for changes made by system upgrades, but it retrieves all versions for changes made by users, not just the current version.") from the parent instance and [resolve any collisions](https://servicenow-prod.fluidtopics.net/rHCSjCvfuIgcZLrCC0FLlQ "A collision is detected when the pulled version and the current local version are modifications of a different version, indicating that someone else has modified the same record that you have modified. The team dashboard displays the number of collisions between the local and the parent instance.").  
   You cannot push changes to the parent instance if collisions are
   detected.
   {#t_PushAVersion__step-3-pull-versions}
{#t_PushAVersion__step-3-pull-versions}
4. In the control panel, click Push.  
   The Push Changes page opens.
5. Provide a Name for the changes.
6. Review the list of changes to ensure that the correct changes are included.

   | Option | Description |
   | To remove changes that you do not want to push | Select the check boxes beside the rows and select Do Not Push from the Actions choice list |
   | To add changes | Click Cancel and repeat the procedure from [step 2](https://servicenow-prod.fluidtopics.net/mwJGlSYOeysuepco8aeJTg#t_PushAVersion__step-2-queue-local-changes) |
   |-|-|

   {#t_PushAVersion__choicetable_qtn_cmc_bq}  
7. **Optional:** Edit the name.  
   The name identifies the push record on the development instance and the local Update Set record on the parent instance.
8. **Optional:** Enter comments.  
   The comments are added to the push record on the development instance and the local Update Set record on the parent instance.
9. Click Push Changes.  
   The system initiates a pull to ensure that there are no collisions before the push proceeds.
   * If collisions are detected, the push is automatically canceled and you must repeat the procedure from [step 3](https://servicenow-prod.fluidtopics.net/mwJGlSYOeysuepco8aeJTg#t_PushAVersion__step-3-pull-versions).
   * If no collisions are detected, the changes are staged on the parent instance. On the parent, each version is validated and then committed in the correct order to maintain dependencies between records. For example, a new table is committed before a field on that table to ensure the field is properly created.
   {#t_PushAVersion__ul_jcy_nmc_bq}  
   Note:  
   You cannot push if there is a version conflict between instances or the pushing instance has changes in the Awaiting Code Review stage.
10. On the completion page, click Show Results.
11. Review the push record for any errors or skipped changes.  
    * Changes with a state of Pushed were committed on the parent instance.
    * Changes with a state of Skipped were not committed on the parent instance and remain queued as local changes on the development instance.
    {#t_PushAVersion__ul_e3l_wmc_bq}
12. For each skipped change, review the log message to determine why the change was skipped.  
    Develop any changes that are necessary to commit the desired version on the parent instance, and then push them. Some examples of why a change may be skipped include:
    * A table does not exist on the parent because it was created when you activated a plugin on the development instance. Ensure the plugin is activated on the parent and push the change again.
    * An error occurred during the push. Try to push again.
    * The current version is invalid. Revert to a previous version and make the change again to ensure the version is valid
    * An error occurred on the parent during the push. The Log field on the push record contains the exception message. Review the system logs on the parent instance and troubleshoot any problems with the instance.
    {#t_PushAVersion__ul_afz_ymc_bq}  

*[\>]: and then