{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":31711,"path":"it-service-management/change-management/c_ChangeStateModel.md","title":null,"bundle":null,"doc_type":null,"release":null,"body":"---\ntitle: Legacy: State model and transitions\ndescription: Change Management offers a state model to move and track change requests through several states.\nlocale: en-US\ncanonical_url: https://www.servicenow.com/docs/r/australia/it-service-management/change-management/c\\_ChangeStateModel.html\nrelease: australia\nproduct: Change Management\nclassification: change-management\ntopic_type: concept\nlast_updated: \"2026-03-12\"\nreading_time_minutes: 5\nbreadcrumb: [Configure, Change Management, IT Service Management]\n---\n\n# Legacy: State model and transitions\n\nChange Management offers a state model to move and track change requests through several states.\n\n**Note:** The change states functionality has been replaced with change models since the Quebec release. For more information, see [Create a Change model](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/change-management/create-a-change-model.md).\n\n\\[Omitted image \"change-state-model.png\"\\] Alt text: State transitions in a normal change request\n\nThe following table provides a list of all 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**.\n\n<table id=\"table_stq_kft_zs\"><thead><tr><th>\n\nState\n\n</th><th>\n\nDescription\n\n</th><th>\n\nState value\n\n</th></tr></thead><tbody><tr><td>\n\nNew\n\n</td><td>\n\nChange 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 prior to submission.\n\n</td><td>\n\n-5\n\n</td></tr><tr><td>\n\nAssess\n\n</td><td>\n\nPeer review and technical approval of the change details are performed during this state.\n\n</td><td>\n\n-4\n\n</td></tr><tr><td>\n\nAuthorize\n\n</td><td>\n\nChange Management and the CAB schedule the change and provide final authorization to proceed.\n\n</td><td>\n\n-3\n\n</td></tr><tr><td>\n\nScheduled\n\n</td><td>\n\nThe 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.\n\n</td><td>\n\n-2\n\n</td></tr><tr><td>\n\nImplement\n\n</td><td>\n\nThe 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.\n\n</td><td>\n\n-1\n\n</td></tr><tr><td>\n\nReview\n\n</td><td>\n\nThe 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.\n\n</td><td>\n\n0\n\n</td></tr><tr><td>\n\nClosed\n\n</td><td>\n\nAll review work is complete. The change is closed with no further action required.\n\n</td><td>\n\n3\n\n</td></tr><tr><td>\n\nCanceled\n\n</td><td>\n\nA 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.\n\n</td><td>\n\n4\n\n</td></tr></tbody>\n</table>Normal, standard, and emergency changes progress through states in different ways.\n\n## State progress for different changes\n\n-   Normal changes progress through all states.\n-   Standard changes are considered to be pre-authorized, so they bypass the **Assess** and **Authorize** states that trigger approval records. Approving these changes progress the change to the next appropriate state. Rejecting these changes send them back to **New** state.\n-   Emergency changes are similar to standard changes, except that they must be authorized.\n\n## Revert a change request to a New change\n\nChange Management allows the Emergency and Normal change types to be reverted to the new state which is the first approval state using the **Revert to New** action from the **Context** Menu. This action is performed if the approval was requested and the submitter recognizes that not all configuration item in the scope of the change is included before submitting for approval.\n\n-   To modify the Normal change request to the New state, modify the state of a change request from **Assess** state to **New** state by clicking **Revert to New** from the Context menu.\n-   To modify the Emergency change request to the New state, modify the state of a change request from **Authorized** state to **New** state by clicking **Revert to New** from the Context menu.\n\n    **Note:** When you revert to **New** from the **Assess** state or the **Authorized** state, the workflow is restarted and all pending approvals are cancelled.\n\n\n## Modify change request type\n\n-   A new ACL for change\\_request.type has been added that allows modification of the **Type** field in change request when the change request is in a **New** state and no approvals have been generated yet for it.\n-   In case of **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**.\n-   In case of **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**.\n-   If a **Normal** or **Emergency** change request is rejected, the state of the change request is set to **New**. As the state of the change request is **New**, you can modify the type of the change request again. For example, if your **Emergency** change request is rejected on the grounds that the change request is **Normal**, you can modify the **Type** of the change request to **Normal** and resubmit the change request.\n\n## Disabled Cancel change action\n\nThe 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.\n\n## Change model attributes\n\nThe Change Manager has the option to mandate specific actions when a Change Request is moved to a specific state. Attributes assigned to that state determine what actions can take place.\n\nBy default, there are two attributes to manage a change request:\n\n-   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.\n-   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.\n\n-   **[Legacy: Add a state to the state model](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/change-management/t_AddANewState.md)**  \nYou can add a new state to the existing state model for different change types based on the requirements of your organization.\n-   **[Configure state model transitions](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/change-management/t_ConfigStateModelTransit.md)**  \nYou can use script includes or UI policies to configure state models and the criteria for moving change requests from one state to another.\n\n**Parent Topic:**[Configuring Change Management](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-service-management/change-management/configure-change-management.md)\n\n"}}