Role required: change_manager.
To create a change, please complete the following steps:
- Navigate to Change Control → Create New;
- Fill in the form and click Save.
The form description
| Field | Mandatory | Description |
|---|---|---|
| Number | Y | This field is populated automatically and contains a change request number looking like (an example) CHGXXXXXXX. |
| 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. |
| Caller | Y | The request originator. |
| Service | Y | Service affected by this change request. |
| Related CIs | N | Service-related CI that will be affected by this change request. |
| 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. |
| Assigned Group | Y | Specify a responsible group to work on the request. When an incident is assigned to a responsible group, then the Assigned User field becomes non-mandatory. The same goes for other task objects, like change requests, or service requests. |
| Subject | Y | A brief description of the request. |
| Reason | Y | A justification of the request. |
| Description | N | A detailed description of the request. |
| State | Y | This field displays the work state and progress. 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. |
| Probability | Y | The level of possibility of disruptive or harmful event occurrence. Possible 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:
|
| 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:
|
| 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 | ||
| Possible Conflicting Changes | Y | Change requests that have time overlap with this request. It possibly can impact request implementation. This field is populated automatically. |
| Planned Start Date | Y | 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 Date | Y | 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 | Y | 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 Note | Y | 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). |
| Actual Start | Y | Pick a date and time when the request was started processing. The responsible person must fill this field. |
| Actual End | Y | 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 that specifies 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).C |
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. |
