Deployment request states

  • Release version: Australia
  • Updated March 12, 2026
  • 2 minutes to read
    • Summarize
    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

    A deployment request can exist in various states throughout the release process, each indicating its progress and the actions required for successful deployment. Understanding these states helps ServiceNow customers manage their deployment requests effectively.

    Show full answer Show less

    Key Features

    • Draft: The initial state where the request is not yet linked to a release. Developers can add update sets here and should only move to the next state when confident in the request's completion.
    • Ready for Assessment: Indicates the request is complete and triggers assessment processes, including automated tests and instance scans.
    • Assessing: During this phase, tests and checks are conducted. The outcome determines whether the request is ready for deployment or requires further reconciliation.
    • Reconciling: Open deployment tasks generated from assessments must be resolved before moving to the next stage. This may involve code changes or approvals.
    • Ready for Deployment: All necessary assessments and reconciliations are complete. The request is locked, and changes cannot be made unless canceled.
    • Deploying: The actual deployment process of the update sets begins.
    • Complete: The request has been successfully deployed.
    • Failed: Indicates issues requiring manual resolution before the request can be resubmitted.
    • Cancelled: The request has been manually canceled.

    Key Outcomes

    By understanding the deployment request states, ServiceNow customers can ensure a smoother release process, effectively manage tasks, and quickly address any issues that arise during deployment, leading to more successful outcomes and timely releases.

    A deployment request might be in one of several different states during the release process.

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