Processing Change Requests

Assigning and Updating Change Requests

How to assign a change request

Open a change request you want to assign;
Press a magnifier icon in the Assigned User or the Assigned Group field;
Select the responsible person or group to assign the change request;
Press Save.

How to update a change request

Open a change request you want to update;
Update the fields that you want to make changes to;
Press Save.

Create Relationships

You can create relationships between changes and other types of tasks. For this, please complete the following steps:

Open the change request you want to work on;
Scroll down the page, then press the Related Records tab;
You can create these types of relationships:
1. Incidents Resolved by this Change;
2. Incidents Caused by this Change;
3. Problems Resolved by this Change;
4. Problems Caused by this Change;
5. Related Changes;
6. Related Request.
To create relationships for the Incidents Resolved by this Change, Incidents Caused by this Change, Problems Resolved by this Change, Problems Caused by this Change, Related Changes, please complete the following steps:
1. Press a lock icon, then press a magnifier icon;
2. In the new window that was appeared choose a necessary option;
3. Press the lock icon again and then press Save.
To create relationships for the Related Request, please complete the following steps:
1. Press a magnifier icon;
2. In the new window that was appeared choose a necessary option;
3. Press Save.

Relationship Types

Type	Description
Incidents Resolved by this Change	The incidents specified will be resolved after resolving this change request.
Incidents Caused by this Change	This change request is the cause of the incidents specified.
Problems Resolved by this Change	The problems specified will be resolved after resolving this change request.
Problems Caused by this Change	This change request is the cause of the problems specified.
Related Changes	This change request has related change requests.
Related Request	This change request has related service requests.

ченджи моэно создавать из проблемов,

емердженси из сендж контролов

ченджи из инцидентов?

множественная горизонтальная связь без иерархии

стандартные чейнджи и как его создать

Change Request Authorization

CABs will be also mentioned here as well

автоматически переходит в шедулед

осветить механизм

апрувал тикеты

по разному формируются CABы в зависимости от риска и его вероятности (probability).

обязательно осветить

есть в документации на Яндекс.Диске

если все auth ticekts заапрувлены - все в scheduled, если зареджектили один - canceled все, если change из aurh в reg, то все тикеты падают в cancelled

Basing on the SimpleOne state model, when the change request has been fully processed (scheduled, implemented, and reviewed, it must be closed. When closing the incident, the agent must provide the closure code.

Closure code

This code specifies an option of the closure. SimpleOne has the following options:

Option	Description
Implemented	This state displays that the change request was fully implemented.
Partially Implemented	This state displays that the change request was implemented with some exclusions that do not affect the critical functionality of the service.
Not Implemented	This state displays that the change request was not implemented.
Cancelled	This state displays that the change request was cancelled because of authorization failed or cancelled by the caller.
Backout	This state displays that the change request implementation was not successful, and the previous state of service (or CI) was restored.