---
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


---

# Deployment request states

# Deployment request 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 Deployment request states

Deployment requests in ServiceNow progress through multiple states during the release process, each representing a key phase in preparing, assessing, and executing deployments.
Understanding these states helps ensure smooth coordination between developers, testers, and release managers, and supports automated checks and manual interventions where necessary.
Show full answer Show less  

## Deployment Request States and Their Purpose

* **Draft:** The initial state where the deployment request is not yet linked to a release. Developers add update sets here and keep the request until the work is complete and ready to be assessed.
* **Ready for Assessment:** The developer signals the deployment request is functionally complete and ready for evaluation. This state triggers automated assessments including tests, instance scans, and playbook executions.
* **Assessing:** Automated tests (like ATF), instance scans, and other checks run to verify the deployment's suitability. Update sets are moved to the test instance. The assessment results determine if the request is ready or if deployment tasks are needed to fix issues.
* **Reconciling:** Open deployment tasks generated during assessment must be addressed. These tasks may require code fixes, configuration updates, or approvals. Once all tasks are resolved, the request is reassessed.
* **Ready for Deployment:** All assessments and reconciliations are complete; the request is locked and no further update sets can be added. On-demand requests proceed immediately; scheduled requests wait for their release time.
* **Deploying:** The deployment request is actively deploying update sets as part of the release process.
* **Complete:** The deployment request was successfully deployed.
* **Failed:** The deployment encountered issues requiring manual intervention before it can be resubmitted.
* **Cancelled:** The deployment request was manually canceled by a user.

## Practical Implications for ServiceNow Customers

This state model enables customers to manage deployment requests with clear checkpoints and automated validations, reducing deployment risks and improving quality control. By following these states, teams can track progress, identify and resolve issues early, and ensure deployments occur only when fully ready. Automated assessments and deployment tasks provide actionable feedback, helping maintain deployment integrity and compliance.  
A deployment request might be in one of several different states during the release process.
{#deployment-request-states__table_lv2_s4j_1gc__entry__2}

| State | Description |
|-|-|
| Draft | The deployment request hasn't yet been associated with a release. Draft is the only state in which an update set can be added to a deployment request. A developer keeps their deployment request in Draft state until they believe the work associated with it is complete. It shouldn't be moved into the Ready for Assessment state until the developer is comfortable with it being deployed as-is. |
| Ready for Assessment | The developer creating the deployment request has determined that it's a functional and complete unit and is ready to be deployed. This state is the triggering condition for the assessment playbook. Immediately after the developer selects Ready to Assess, assessment will begin, running the processes, tests, and checks defined in the release pipeline. |
| Assessing | Automated Test Framework (ATF) tests are running, instance scans are running, and any Playbooks (PAD) process that will determine the suitability of this deployment request to be deployed is executed. Update sets contained within the deployment request are being moved from the development instance to the test instance. The Assessment phase results in one of two conclusions: * The deployment request is ready, with no findings requiring action (by means of a deployment task). * The assessment surfaced one or more findings that must be reconciled for the deployment request to be ready. Deployment tasks will be generated and assigned to the user/group nominated in the request. The outcomes of these tasks are recorded against the request, and the request will be reassessed. This loop continues until the request is ready or canceled. {#deployment-request-states__ul_hk5_dpj_1gc} |
| Reconciling | Open deployment tasks have been generated for action. These tasks must have an outcome for the assessment to be completed and the deployment request to move into the next stage. The sample pipelines included in ReleaseOps will create deployment tasks for preview conflicts and ATF test failures. Some outcomes might involve code changes or additions, updates to test suites or configuration, or approvals or sign-offs. After all open deployment tasks have an outcome, the request is reassessed. |
| Ready for Deployment | All assessments have been performed, and all reconciliations are complete. No new update sets can be added in this state, and the deployment request is effectively locked. If changes must be made at this point, the deployment request must be canceled. At this point, if the deployment request is an on-demand deployment, it will continue immediately into deployment. Otherwise, it waits for the scheduled time of the release before continuing. |
| Deploying | A release is in the process of deploying the update sets associated with this deployment request. |
| Complete | The deployment request was successfully deployed as part of a release. |
| Failed | The deployment request had a problem that requires manual intervention or resolution to be resubmitted for a release. |
| Cancelled | The deployment request was manually canceled. |
[ ]

{#deployment-request-states__table_lv2_s4j_1gc}