Create Change Tasks
If solving change requests requires participation of several departments, then you can create a сhange task for each of them.
To create a change task, please complete the following steps:
- Navigate to Change Enablement → All Change Requests and open the change request you need to work on.
- Open the Change Task tab in the Related Lists area.
- Fill in the form.
- Specify start and end dates in the Schedule tab for task implementation.
- Click Save or Save and Exit.
| Field | Mandatory | Description | ||
|---|---|---|---|---|
| Number | Y | This field contains a change request task number in CHTXXXXXXX format. It is populated automatically. | ||
| Parent | Y | This field is populated automatically with the number of the parent change request. | ||
| Assignment Group | Y | Choose a responsible group you wish to assign the task to.
There is a dependence between Assigned User and Assignment Group fields. Refer to the Task Auto Assignment article to learn more. | ||
| Assigned User | Y | Choose a responsible person you wish to assign the task to.
There is a dependence between Assigned User and Assignment Group fields. Refer to the Task Auto Assignment article to learn more. | ||
| Subject | Y | Specify the task subject. | ||
| Description | N | Describe the task by giving more details. | ||
| Phase | Y | Specify the change phase, depending on its schedule. | ||
| Type | N | Define the type of change task.Available options:
Task type can be customized based on the business needs (for example, Deployment Task, Code Review Task, Documentation Task). | ||
| State | Y | Specify the task state. Available choice options:
| ||
| On Hold | N | Select this checkbox to show that works on the task are paused. | ||
| Schedule tab | ||||
| Planned Start Datetime | N | The date when the assigned person is supposed to start working on this task. | ||
| Planned End Datetime | N | The date when the task should be in the Completed or Closed state. | ||
| Previous Task | N | The task that was done before. | ||
| Actual Start Datetime | N | The date when the assigned person started to work on this task. The agent should fill in this field. | ||
| Actual End Datetime | N | The date when the assigned person finished the work on this task. The agent should fill in this field. | ||
| Next Task | N | The task that will be done after. | ||
| Info |
|---|
You can create as many change tasks as you need. |
Change Task State Model
Create a Change Request Announcement
Create an announcement informing related to the Change Request processes.
To create a Change Request announcement, please perform the following steps:
- Navigate to Change Enablement → All Change Requests and open a change request you need to work on.
- Click the Create Announcement button in the change request form.
- Fill in the fields.
- Click Save or Save and Exit.
Field | Mandatory | Description |
|---|---|---|
Number | Y | This field is populated automatically with the announcement number in ANCMXXXXXXX format. |
| State | Y | This field is populated automatically with New. |
| Related Change | Y | This field is populated automatically with the identifier number and subject of the change request. |
| Announcement Type | Y | Available options:
|
| Service | Y | Select the service affected by the change request. |
| Recipient Email | N | Specify the email of the announcement recipient. You can add more than one email, separated by commas. |
| Reviewer's Email | N | Specify the email of the announcement reviewer. You can add more than one email, separated by commas. |
| via Email | N | Select this checkbox to send this announcement via email. It will be sent to all addresses specified in the Recipient Email field. |
| via Portal | N | Select this checkbox to display this announcement on the Service Portal in the Portal Announcements area. |
| Subject | Y | This field will be populated automatically with the change request subject. |
| Announcement Body | N | Type the message you need to share with users about this incident. You can design the announcement body using the built-in editor functionality, such as formatting, working with tables and media, lists, styles, and headings. |
| Signature | N | Reference to the Announcement Signature. |
| Description | N | Describe the announcement. |
Create Relationships
You can create relationships between changes and other types of tasks.
Relationship Types
Type | Description |
|---|---|
| Caused by Incidents | This change request is the cause of the incidents specified. |
| Caused by Problems | This change request is the cause of the problems specified. |
| Related Articles | This change request related to the Knowledge Base Articles specified. |
| Related Inquiry | This change request is related to the inquiry specified. |
| Resolved Incidents | The incidents specified will be resolved after resolving this change request. |
Resolved Problems | The problems specified will be resolved after resolving this change request. |
To add a new relationship, please complete the following steps:
- Navigate to Change Enablement → All Change Requests and open the change request you want to work on.
- Open the Related Records tab.
- Click the magnifier icon
next to the appropriate field. - In the window appeared, choose a necessary option.
- Click Save to apply changes
The scheme below illustrates state models of the change requests of three different types:
- Standard Change
- Normal Change
- Emergency Change
Also, you can find a brief description of every state further in the article.
| Info |
|---|
Normal Change model is relevant when the Change Authority field has the Local Authorization value. In this case, the Authorization stage is skipped. |
States Description
Registered
This state is for the newly created change requests.
- If this is a Standard change, then it transitions straight to the In Progress state, as the Standard is a pre-approved type.
- If this is a Normal or Emergency change request, then the request transitions to the Authorization state. Also, in case of a Normal Change, this step can be skipped, and the Authorization state can be assigned right away.
Authorization
This state is mandatory for Normal or Emergency changes. In this state, the request must be reviewed and authorized by the responsible persons or groups (see more on the Change Request Authorization). After all authorization steps have been passed, the change request transitions to the Scheduled state.
Scheduled
In this state, the change request has the following prerequisites:
- Planned start date
- Planned end date.
So it is preliminary known when the change will be implemented.
In Progress
This state displays that the request is in progress of implementation now. When the work is over, the state has to be changed to Completed.
Completed
After the work is over and the request is transited into this state, the requester can perform the tests and give feedback on the results of the implementing. After this, change the state to Closed.
Post Implementation Review
When the request is completed (whether successfully or not), the Change Advisory Board (CAB) has a right to perform Post Implementation Review on the basis of the implementing. It is a good practice that allows gaining the "lessons learned" after the implementation, especially if there were any issues on the way.
For this, the change request state must be changed to the Post Implementation Review state from the Completed state. After the review, similarly to the Completed state, mark it as Closed.
Closed
All activities on this change request are over, and it cannot be reopened.
| Table of Contents | ||||
|---|---|---|---|---|
|
The scheme below illustrates state models of the change requests of three different types:
- Standard Change
- Normal Change
- Emergency Change
Also, you can find a brief description of every state further in the article.
| Info |
|---|
Normal Change model is relevant when the Change Authority field has the Local Authorization value. In this case, the Authorization stage is skipped. |
States Description
Registered
This state is for the newly created change requests.
- If this is a Standard change, then it transitions straight to the In Progress state, as the Standard is a pre-approved type.
- If this is a Normal or Emergency change request, then the request transitions to the Authorization state. Also, in case of a Normal Change, this step can be skipped, and the Authorization state can be assigned right away.
Authorization
This state is mandatory for Normal or Emergency changes. In this state, the request must be reviewed and authorized by the responsible persons or groups (see more on the Change Request Authorization). After all authorization steps have been passed, the change request transitions to the Scheduled state.
Scheduled
In this state, the change request has the following prerequisites:
- Planned start date
- Planned end date.
So it is preliminary known when the change will be implemented.
In Progress
This state displays that the request is in progress of implementation now. When the work is over, the state has to be changed to Completed.
| Note |
|---|
When the Assigned User field changes its value, the change state changes from the In Progress to Assigned value. |
Completed
After the work is over and the request is transited into this state, the requester can perform the tests and give feedback on the results of the implementing. After this, change the state to Closed.
Post Implementation Review
When the request is completed (whether successfully or not), the Change Advisory Board (CAB) has a right to perform Post Implementation Review on the basis of the implementing. It is a good practice that allows gaining the "lessons learned" after the implementation, especially if there were any issues on the way.
For this, the change request state must be changed to the Post Implementation Review state from the Completed state. After the review, similarly to the Completed state, mark it as Closed.
Closed
All activities on this change request are over, and it cannot be reopened- .
| Table of Contents | ||||
|---|---|---|---|---|
|