--- 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 --- # Parallel stages in Azure DevOps release pipelines # Parallel stages in Azure DevOps release pipelines {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 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 Parallel stages in Azure DevOps release pipelines ServiceNow DevOps now supports parallel stages in Azure DevOps release pipelines, enabling concurrent execution and real-time display of these stages within the DevOps pipeline UI. This feature accelerates release processes by running multiple tasks simultaneously instead of sequentially, especially useful for pipelines integrating several test and quality tools. However, parallel stage support is limited to release pipelines; build pipelines continue to show stages sequentially in the UI. Show full answer Show less ## Key Features * **Parallel Stage Execution:** Multiple jobs and nested parallel stages can run concurrently, reducing total pipeline execution time. * **Real-time Pipeline UI Display:** The DevOps pipeline UI mirrors the Azure DevOps GUI, showing parallel stages and their details as they execute. * **ServiceNow DevOps Release Gate Integration:** A base system release gate with pre-deployment conditions can automatically create change requests after all upstream parallel stages complete. These change requests aggregate data such as commits, work items, test summaries, software quality results, and artifact versions. * **Change Request Workflow:** The production deployment stage waits for the change request approval before proceeding, ensuring governance and compliance. ## Important Considerations and Upgrade Notes * Change requests should not exist in stages containing parallel jobs. * For new installations, the Upstream execution column in the Task Executions table is hidden; existing customizations remain unaffected. * A change request should not be the first job in any parallel stage to avoid deadlocks. * Previously executed pipelines before upgrading will continue displaying parallel stages serially; new executions after upgrade will show true parallel processing. * If the ServiceNow DevOps release gate is enabled on multiple start stages, it might trigger multiple pipeline executions, but only one package is associated per execution. * There is a known deadlock issue where change creation can be delayed due to Azure DevOps job reporting order, potentially causing a 500 error; rerunning the job resolves this. ## Practical Benefits for ServiceNow Customers By leveraging parallel stages in Azure DevOps release pipelines integrated with ServiceNow DevOps, customers can: * Significantly reduce release pipeline duration by executing tasks concurrently. * Gain real-time visibility of parallel job progress and results within the ServiceNow DevOps UI. * Automate change request creation that consolidates relevant upstream details, improving change management and compliance. * Ensure deployment gates enforce approval workflows before production deployment, enhancing risk control. Parallel stages in a release pipeline are now processed concurrently and displayed in the DevOps pipeline UI in real time. Base system pre-deployment conditions and release gates enable you to create change requests that include details from parallel stages. ## Base system parallel stage support for Azure DevOps {#parallel-stages-ado-release-pipelines__section_kvv_nrw_drb} Organizations use parallel stages to automate and speed up release processes for tasks that can be performed in parallel. For example, a release pipeline has integrated multiple test and software quality tools and has jobs configured to run in parallel. Not running each job sequentially significantly speeds up the release pipeline execution. ServiceNow DevOps supports processing parallel stages in release pipelines and displays the stages in a parallel view in the DevOps pipeline UI. Effectively, the DevOps pipeline UI replicates the Azure DevOps GUI in real time. You can also see the details of the processed stages in the pipeline UI. Important: Support for parallel stages is restricted to Release pipelines. Build pipelines continue to appear in a sequential or serial manner in the DevOps pipeline UI, even if parallel stages are configured for build pipelines in Azure DevOps. Figure 1. ADO pipeline with parallel stages Sample ADO pipeline with parallel stages pipeline { agent any stages { stage('Build') { steps { echo 'Building...' // Your build steps here } } stage('Test') { parallel { stage('Unit Tests') { steps { echo 'Running unit tests...' // Your unit test steps here } } stage('Integration Tests') { steps { echo 'Running integration tests...' // Your integration test steps here } } stage('Additional Tests') { steps { script { parallel( 'Nested Stage 1': { echo 'Running nested parallel stage 1...' // Your nested parallel stage 1 steps here }, 'Nested Stage 2': { echo 'Running nested parallel stage 2...' // Your nested parallel stage 2 steps here } ) } } } } } stage('Deploy') { steps { echo 'Deploying...' snDevOpsChange changeRequestDetails: '{ "attributes": {"chg_model": "e55d0bfec343101035ae3f52c1d3ae49","standard_change_template"="563504cc47410200e90d87e8dee490e2"},"autoCloseChange": false}',changeStepTimeOut: 18000, pollingInterval: 60 // Your deploy steps here } } } } ## ServiceNow® DevOps release gate in pre-deployment conditions to create Change requests {#parallel-stages-ado-release-pipelines__section_yw3_scx_drb} A base-system ServiceNow DevOps Release Gate is added along with pre-deployment conditions. Enable base system deployment gates that are configured to call the ServiceNow AI Platform instance, to create a change request before the deploy to production stage. Change requests are now created after all previous (upstream) stages complete processing. The change request captures relevant details from all upstream stages and displays them in the following corresponding related lists. * Commits * Work Items * Test Summaries * Software Quality Summary * Artifact Versions {#parallel-stages-ado-release-pipelines__ul_skg_svw_drb} After the pipeline execution completes processing the parallel stages preceding the production deployment stage, a change request is automatically created and mapped to the deploy to production stage in the Pipeline Executions view. The production stage completes processing once the change request is approved. From the Pipeline Execution view of the relevant pipeline, click the Pipeline UI related link to view the real-time state of the pipeline as it appears in Azure DevOps. The associated artifact details which are sourced from the build pipeline, Test Results, Software Quality Summary Results display on the pipeline UI. ## Change creation sequence for parallel jobs {#parallel-stages-ado-release-pipelines__section_lz3_tzv_ddc} Job information from Azure is received in ServiceNow during the following times: 1. On the completion of a stage. 2. When the register-change step executes. {#parallel-stages-ado-release-pipelines__ol_rwc_bbw_ddc} Azure provides job information sequentially based on job queue time, despite jobs potentially running in parallel. Consequently, if the register-change step executes while a parallel job queued earlier remains unfinished, the system assumes the parallel job is an upstream task, causing the change creation process to wait for its completion. However, stage completion notifications aren't received until all jobs, including the register-change job, have finished. This creates a deadlock scenario where the change process in ServiceNow waits for the parallel job to complete, while the parallel job waits for the stage completion notification. The stage completion in turn waits for the register-change job to finish. Due to this deadlock, by the time the change is created, the Azure pipeline job has already failed, leading to the 500 error in the event API. Rerunning the job resolves the issue as the previously queued parallel jobs are marked as completed. ## Upgrade Considerations {#parallel-stages-ado-release-pipelines__section_dpd_c4b_2rb} Ensure that you review the following considerations before upgrading. Important: A change request should not exist in a stage which contains parallel jobs. * The Upstream execution column in the Task Executions table is not displayed for fresh installations. Any customizations that you have made using the Upstream execution column prior to the upgrade are unaffected. * If stages are running in parallel, a change request should not be the first job in any stage. * After upgrading, new release pipeline executions process parallel stages concurrently and display parallel stages and associated details in the pipeline UI. Azure DevOps release pipelines that are already executed and stored in ServiceNow DevOps before the upgrade remain unaffected and continue to display parallel stages (that are already executed and persisted) in ServiceNow DevOps serially. * If the pre-deployment ServiceNow DevOps release gate is enabled in more than one start stage in a release pipeline with multiple start stages, it might result in multiple pipeline executions. {#parallel-stages-ado-release-pipelines__ul_c1y_qpb_2rb} Note: A package is created for each start stage but any one package is associated per pipeline execution.