---
sourceDocument: Brazil Build or modify applications
sourceDocumentLink: https://www.servicenow.com/docs/r/application-development

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Release states

# Release states {#ariaid-title1}

Release version: Brazil  
Updated September 10, 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 Release States in ServiceNow Release Management

In ServiceNow Release Management, a release progresses through various defined states that govern its lifecycle from creation to completion.
Understanding these states helps you manage deployment schedules, validate deployment readiness, and respond to issues effectively during the release process.
Show full answer Show less  

## Release States and Their Roles

* **Draft:** Initial state where the release is created but inactive. Releases in this state do not trigger deployment actions or appear as deployment targets. This state allows you to plan schedules in the future, requiring manual activation to proceed.
* **Active:** The release is open and awaiting the freeze time. Deployment requests can still be added or removed, and requests attached are actively assessed or reconciled.
* **Preparing:** The deployment is frozen. All deployment requests must be validated as ready or deferred. The release ordering is established, and changes to deployment requests are restricted except by release administrators. This state is triggered automatically based on the freeze time or associated change management record.
* **Ready for Release:** Final state before deployment where no changes to deployment requests are allowed. The release has passed all validation checks and manual pipeline steps are completed, indicating full readiness for deployment.
* **Deploying:** The process of moving build artifacts to the target instance is underway. This state transition is scheduled and may depend on an associated change management record's timing.
* **Reconciling:** Indicates deployment issues requiring manual intervention. A deployment task is created to resolve conflicts or problems encountered during deployment.
* **Complete:** Successful completion of the release deployment without issues.
* **Cancelled:** The release deployment was manually stopped before starting.
* **Failed:** Deployment encountered failures or issues preventing completion. Common causes include retrieval errors with update sets, violation of deployment order, or unexpected commits.

## Practical Implications for ServiceNow Customers

Understanding these release states enables you to:

* Plan and schedule releases effectively by leveraging the Draft and Active states.
* Ensure deployment requests are validated and ordered correctly during the Preparing and Ready for Release states.
* Monitor deployment progress and handle issues promptly through the Deploying and Reconciling states.
* Track final outcomes to confirm successful releases or address failures and cancellations.

Release state transitions can be automatic based on predefined freeze and release times or linked change management records, allowing you to align releases with broader change control processes.  
A release might be in one of several different states during the release process.
{#release-states__table_d2v_hmj_1gc__entry__2}

| State | Description |
|-|-|
| Draft | The initial state of a release. ReleaseOps doesn't act on any release in this state, regardless of the release schedule set. Draft releases don't appear in a deployment request as a target. This enables the creation of schedules into the future, but they must be manually moved into the Active state before deployment requests can be added and deployed. |
| Active | The release is open in this state, and waiting for the freeze time to arrive. While in this state, attached deployment requests are actively in the Assessing or Reconciling state. Deployment requests can still be added at this point, or removed (by the developer or release admin). |
| Preparing | The deployment is frozen. All deployment requests attached to the release are validated to be Ready for Deployment, or else they're deferred. The release ordering has been generated. A release administrator can remove a deployment request. This change of state is derived from the scheduler based on the freeze time. Note: If the release is associated with a change management record, the release time is determined by that change management record. |
| Ready for Release | All deployment requests are finalized. No deployment requests can be added to or removed from the release, and the release has passed all checks and is eligible for deployment. Any manual steps within the pipeline playbook have been completed. |
| Deploying | The act of finalizing the move of all build artifacts to the destination instance. This change of state is derived from the scheduler, based on the release time. Note: If the release is associated with a change management record, the release time is determined by that change management record. |
| Reconciling | There was a problem with at least one deployment request in the release that requires manual intervention. From the playbook, a deployment task will be created for a preview conflict. |
| Complete | The release completed without issue. |
| Cancelled | The deployment of the release was manually canceled before commencement. |
| Failed | The deployment was either unable to be completed or completed with issues. Common reasons for deployment failure include: * An update set is unable to be retrieved. * An update set that was planned to be retrieved was already retrieved and committed. The commitment is deemed a failure as the defined order of update set deployments has been broken (unless this update set was the first in the ordering). * An update set was committed unexpectedly after retrieval. {#release-states__ul_gg3_pmj_1gc} |
[ ]

{#release-states__table_d2v_hmj_1gc}