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

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# State model and transitions

# State model and transitions {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read  
Change Management offers a state model to move and track change requests through
several states.  
Figure 1. Example of state transitions for a normal change request

The following table lists the states that a change request can progress through. Email notifications can be sent to the user who requested the change when it progresses to the following states: Scheduled,
Implement, Review, and Canceled.
{#c_ChangeStateModel__table_stq_kft_zs__entry__3}

| State | Description | State value |
|-|-|-|
| New | Change request is not yet submitted for review and authorization. A change requester can save a change request as many times as necessary while building out the details of the change before submission. | -5 |
| Assess | Peer review and technical approval of the change details take place during this state. | -4 |
| Authorize | Change Management and the CAB schedule the change and provide final authorization to proceed. | -3 |
| Scheduled | The change is fully scheduled and authorized, and is waiting for the planned start date. An email notification is sent to the user who requested the change. | -2 |
| Implement | The planned start date has approached and the actual work to implement the change is being conducted. An email notification is sent to the user who requested the change. | -1 |
| Review | The work has been completed. The change requester determines whether the change was successful. A post-implementation review can be conducted during this state. An email notification is sent to the user who requested the change. Note: You cannot cancel the change request if it is in the Review state. | 0 |
| Closed | All review work is complete. The change is closed with no further action required. | 3 |
| Canceled | A change can be canceled at any point when it is no longer required. However, a change cannot be canceled from a Closed state. An email notification is sent to the user who requested the change. | 4 |
[Table 1. Change states]

{#c_ChangeStateModel__table_stq_kft_zs}

Normal, standard, and emergency changes progress through states in different ways.

## State progress for different changes {#c_ChangeStateModel__section_agv_5dv_fdb}

* Normal changes progress through all states.
* Standard changes are considered to be pre-authorized, so they bypass the Assess and Authorize states that trigger approval records. Approving these changes progresses the change to the next appropriate state. Rejecting these changes sends them back to the New state.
* Emergency changes are similar to standard changes, except that they must be authorized.
{#c_ChangeStateModel__ul_fgx_cdv_fdb}

## Reverting a change request to the New state {#c_ChangeStateModel__section_tms_xdv_fdb}

You can revert emergency and normal change requests to the New state, which is the first approval state, by using the Revert to New action in the form context menu. Use this action when approval was
requested but the submitter recognizes that some configuration items in the scope of the change weren't included.

* To modify the Normal change request to the New state, modify the state of a change request from Assess state to New state by selecting Revert to New from the form context menu.
* To modify the Emergency change request to the New state, modify the state of a change request from Authorized state to New state by selecting Revert to New from the form context menu.  
  Note:  
  When you revert to New from the Assess state or the Authorized state, the workflow is restarted and all pending approvals are canceled.
{#c_ChangeStateModel__ul_ulc_12v_fdb}

## Modifying the change request type {#c_ChangeStateModel__section_vmn_22v_fdb}

* An ACL for change_request.type enables you to modify the Type field of a change request when the change request is in the New state and has no approvals.
* For a Standard change request, you can modify the type of the change request from Standard to Normal or Emergency, if the state of a change request is New.
* For a Normal or Emergency change request, you can modify the type of the change request from Normal to Emergency or vice versa if the state of a change request is New.
* If a Normal or Emergency change request is rejected, the state of the change request is set to New. Because the change request is in the New state, you can modify the type of the change request again. For example, if your Emergency change request is rejected because it is actually a Normal change, modify the Type to Normal. Then resubmit the change request.
{#c_ChangeStateModel__ul_l5x_f2v_fdb}

## Disabled Cancel change action {#c_ChangeStateModel__section_s53_b21_1gb}

The Cancel option for a change request in the Review state is disabled. This restricts cancelling the request when the work is complete and is waiting for review.

## Change model attributes {#c_ChangeStateModel__section_y1v_yy3_fdc}

Change managers can require specific actions when a change request moves to a specific state. Attributes assigned to that state determine what actions can take place.  
By default, there are two attributes to manage a change request:

* allow_ci_modification -- Allows to modify the CI. Attributes are only considered if they are included in a model. If the `allow_ci_modification` attribute is not added to a model, it defaults to its initial state.
* allow_implementation -- Indicates that the change will be implemented. By enabling `allow_implementation`, this feature replaces the implementation states field currently present on the Change model. Both the states listed in the implementation states field and the attribute will be respected.
{#c_ChangeStateModel__ul_mlv_bz3_fdc}
* **[Add a state to the state model](https://www.servicenow.com/docs/UEbX06Kzcj6S2rvwEumZuQ#t_AddANewState)**   
  Add a state to the state model for different change types to meet the requirements of your organization.
* **[Configure state model transitions](https://www.servicenow.com/docs/nHgqrOTyeAikvLcbq~WLkg)**   
  Use script includes or UI policies to configure state models and the criteria for moving change requests from one state to another.