Role required: change_manager.
To create a change, please complete the following steps:
- Navigate to Change Requests.
- Click New and fill in the form.
- Click Save or Save and Exit to apply changes.
The form description
Field | Mandatory | Description |
---|---|---|
Number | Y | This field is populated automatically and contains a change request number looking like (an example) CHGXXXXXXX. |
Caller | Y | The request originator. |
Company | N | A Company to which the request is related. |
Change Type | Y | The change type. Available choice options:
Based on the option picked up there, the request should be authorized differently. To learn more about this, please refer to the Change Request Authorization article. |
Service | Y | Service affected by this change request. |
Related CIs | N | Service-related CI that will be affected by this change request. |
Copy CIs to Originators | N | |
Assigned Group | Y | Specify a responsible group to work on the request. When a change request is assigned to a responsible group, then the Assigned User field becomes non-mandatory. The same goes for other task objects, like incidents, or service requests. |
Assigned User | Y | Specify a responsible person to work on the request. When Assigned User changes to another person, the Change state changes from the In Progress to Assigned value. When a change request is assigned to a responsible group, then the Assigned Group field becomes non-mandatory. The same goes for other task objects, like incidents, or service requests. |
Subject | N | A brief description of the request. |
Reason | Y | A justification of the request. |
Followers List | N | In here, users list who follow the request for tracking updates is displayed. |
State | N | This field displays the work state and progress. Available choice options:
|
Impact | Y | The measure of the effect that a change request may cause on the business processes. Available choice options:
|
Urgency | Y | The measure of time until a change request has an impact on the business. Available choice options:
|
Probability | Y | The level of possibility of disruptive or harmful event occurrence. Possible choice options:
|
Priority | Y | Priority is a function of impact and urgency. It identifies the importance of a request. Available choice options:
|
Risk | Y | Risk is a function of impact and probability. It's a possible event that could cause loss or harm. Available choice options:
|
Change Authority | Y | The person or group who is responsible to authorize the request. This field is populated automatically basing on the value in the Change type field. |
Notes tab | ||
Additional Comments | N | Specify some comments related to this request. These comments will be displayed in the Service Portal view of this request. |
Work Notes | N | Specify work notes related to this request. These notes are not to be displayed in the Service Portal view of this request. |
Schedule tab | ||
Planned Start Datetime | N | Pick a date and time you need the request to be started processing. The responsible person must fill this field before a change request can be processed (state = In Progress). |
Planned End Datetime | N | Pick a date and time you need the request to be finished processing. The responsible person must fill this field before a change request can be processed (state = In Progress). |
Planned Downtime | N | If service downtime is expected, then put down its duration here. The responsible person must fill this field before a change request can be processed (state = In Progress). |
Downtime Notes | N | You can put any notes about planned service downtime here. The responsible person must fill this field before a change request can be processed (state = In Progress). |
Possible Conflicting Changes | N | Change requests that have time overlap with this request. It possibly can impact request implementation. This field is populated automatically. |
Actual Start Datetime | N | Pick a date and time when the request was started processing. The responsible person must fill this field. |
Actual End Datetime | N | Pick a date and time when the request was finished processing. The responsible person must fill this field. |
Actual Downtime | N | If service downtime took place then put down its duration here. |
Planning tab | ||
Preparation | Y | This plan specifies the steps that need to be done and the criteria to be met before implementing the change. The responsible person must fill this field before a change request can be processed (state = In Progress). |
Core Activities | Y | Describe here the process of change implementing. The responsible person must fill this field before a change request can be processed (state = In Progress). |
Validation | Y | The process of how the change must be tested after implementing, The responsible person must fill this field before a change request can be processed (state = In Progress). |
Backout | Y | The plan specifying the processes rollback the system or service or CI condition to its previous state, in case of a failed implementation. The responsible person must fill this field before a change request can be processed (state = In Progress). |
This tab appears when a change request is completed (state → Completed) | ||
Complete originators | N | Select this checkbox to make the originators related to this request be completed along with it. |
Closure Notes | Y | Specify some notes summarizing the implementation process. |
Closure Code | Y | Specify a closure code. For more information, please refer to the Closure Code article. |