Pushing changes

  • Release version: Zurich
  • Updated September 11, 2025
  • 1 minute to read
  • You can push versions of customized records to synchronize your instance to the parent instance.

    Developers should consider the following when preparing to push changes.
    • Push changes when a feature is tested and ready to promote to the parent development instance.
    • Pushing changes to the parent instance only adds the current development version. Changes to previous development versions aren't pushed.
    • Pushing changes creates a local update set on the parent instance that is marked as complete.
    • Transfer the update set or push to move the local changes through your development and test hierarchy.
    • Customize which changes to push to the parent instance.
    • Pushed versions are also tracked as local changes on the parent instances.

    Workflow when pushing changes

    1. Queue a local change for a push

      Application developers can queue a local change for a push to confirm the changes are available to other developers.

    2. Push a version

      Pushing promotes changes from the development instance to the parent instance.

    3. Code reviews

      Team Development administrators can require that pushes undergo code review before accepting pushes.

    4. Approve or reject a push

      Code reviewers must approve or reject a push from the Team Development application.

    5. Check the review status of a pushed change

      If the parent instance requires pushed changes to undergo code review, changes are placed in the Awaiting Code Review stage.

    6. Compare a pushed version to a local version

      Code reviewers can compare the pushed versions to the local versions to see the potential effect of incoming changes.

    7. Back out a push

      Application developers can back out a push to remove unwanted changes.