---
sourceDocument: Australia IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-service-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Execution sequence and waiting logic for rerun jobs

# Execution sequence and waiting logic for rerun jobs {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](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 Execution sequence and waiting logic for rerun jobs

This document outlines the execution sequence and waiting logic differences for rerun jobs in ServiceNow DevOps, specifically when reusing or creating change requests during rerun operations.
It highlights considerations for parallel stages, upgrade impacts, and how rerun attempts interact with pipeline execution and artifact registration.
Show full answer Show less  

## Key Considerations

* **Change Request Restrictions:** Change requests must not be in stages that run parallel jobs. Additionally, a change request cannot be the first job in more than one parallel stage.
* **Parallel Stages Display:** Parallel stages in release pipelines are displayed in the UI as they occur in Azure DevOps, while build pipelines show parallel stages in serial order in the UI.
* **Upgrade Behavior:** The execution logic remains unchanged for first pipeline runs after upgrade. However, rerun attempts from before the upgrade are ignored, so new reruns should be initiated post-upgrade for accurate processing.

## Execution Sequence and Processing Logic

* **Artifact Registration:** Duplicate artifact version registration calls during reruns are ignored, but new package registration calls for the same package name create new packages linked to the rerun. The latest package artifacts are reflected on the change request.
* **Build Pipeline Reruns:** Rerunning a stage triggers subsequent stages rerun in the defined sequence. If a rerun is initiated before the previous attempt completes, the rerun waits until all previous events finish processing.
* **Release Pipeline Reruns:** Stages run sequentially only on the first run. For reruns, each stage must be manually rerun. From the second attempt onward, even parallel stages are processed sequentially.
* **Change Request and Test Results:** When creating a new change request for a rerun stage with tests and software quality scans, only the latest test and scan results appear. If an existing change request is reused, all test and scan results from each attempt are displayed.

## Practical Impact for ServiceNow Customers

Understanding this rerun execution logic helps you manage pipeline reruns effectively, especially in complex scenarios involving parallel stages and change requests. It ensures accurate artifact tracking, proper sequencing of rerun stages, and correct display of test and quality scan results on change requests. Additionally, after upgrading to the Australia release, it is important to initiate new pipeline runs to enable rerun functionality without issues from prior attempts.  
Processing sequence and waiting logic for rerun jobs are different when you reuse or
create a change request as part of a rerun job.

## Existing Considerations {#devops-rerun-waiting-logic__section_ukk_ppm_vqb}

* A change request should not exist in a stage which contains parallel jobs.
* If more than one stage is running in parallel, change request should not be the first job in both the stages.

{#devops-rerun-waiting-logic__ul_k4s_spm_vqb}  
Note:  
Parallel stages in release pipelines are processed and displayed in the pipeline UI as they occur in the Azure DevOps pipeline. Parallel stages in build pipelines are still processed in parallel but appear in a serial order in the pipeline UI.

## Upgrade Considerations {#devops-rerun-waiting-logic__section_vzp_v5m_vqb}

There is no change in the functionality or execution when you run the first pipeline attempt. All stages are processed sequentially and associated tests, software quality scans and change requests are executed and created as modeled.  
Note:  
* Run a new pipeline after you upgrade if you have rerun stages and pipelines before upgrading. Rerun attempts and failed events prior to the upgrade are ignored by ServiceNow DevOps for reattempts.
* If you have only run the pipeline once before upgrade, you can rerun the stage or the pipeline. The rerun functionality applies as designed and is saved in ServiceNow DevOps.
{#devops-rerun-waiting-logic__ul_vl2_kxm_vqb}

## Execution Sequence and processing logic {#devops-rerun-waiting-logic__section_es4_zvm_vqb}

* If the same artifact version registration call is received in reattempt, the registration call is ignored.
* Package registration calls with same package name are not ignored. A new package associated to artifact versions and pipeline execution is created during reattempt. The artifacts that are associated to the latest package, will be shown on the change request.
{#devops-rerun-waiting-logic__ul_izp_cwm_vqb}

From the Azure DevOps GUI, if you rerun a stage in a build pipeline the
subsequent stages reruns are also triggered in it's specified sequence. If you reattempt
processing a pipeline before all the stages of the previous attempt are not complete. The
subsequent attempt waits until all the events in the previous attempt are processed.

For release pipelines, the stages are run in the specified sequence only during the first
run. For subsequent rerun attempts manually run each stage.
In release pipelines even
if stages are running in parallel in Azure DevOps, from the second attempt onwards the
events are processed in the specified sequence.  
* When a new change request is created for a reattempt stage job, and the stage that you're reattempting includes a test and a software quality scan, only the latest Test Summary and Software Quality scan results display on the change request related list.
* When a change request is reused for a rerun stage job, the Test Summary and Software Quality scan results for each attempt displays in the change request related list.
{#devops-rerun-waiting-logic__ul_yg5_s1n_vqb}