Process Change Requests

tip

Role required: change_manager.

Assign and update change requests

To assign a change request, perform the following steps:

1. Navigate to Change Enablement → All Change Requests and open the change request you need to assign.
2. On the General tab, click the magnifier icon next to the Assigned user or Assignment group field.
3. Select the responsible person or group to assign the change request.
4. Click Save or Save and exit to apply the changes.

To update a change request, complete the steps below:

1. Navigate to Change Enablement → All Change Requests and open the change request you need to update.
2. Update the necessary fields.
3. Click Save or Save and exit to apply the changes.

Scheduling

Change requests must be planned and scheduled carefully. Planning and scheduling allow minimizing vital business function disruption.

When scheduling a change request implementation, remember about time overlaps; minimize the effect caused to the multiple services or CI's at implementation time.

Schedule tab

---

To schedule a change request, complete the following steps:

1. Navigate to Change Enablement → All Change Requests and open the change request you need.
2. On the Schedule tab, enter the date and time for the request to start and finish processing into the appropriate fields.
3. After the request was processed, enter the actual date and time.

Schedule tab fields

Field	Mandatory*	Description
Planned start datetime	Y/N	Pick a date and time to start the request processing. Fill in this field before the change request can be processed.
Planned end datetime	Y/N	Pick a date and time to finish the request processing. Fill in this field before the change request can be processed. Learn about automatic state transitions for overdue requests in the Change Types and State Models article.
Change schedule	Y/N	See the Change Schedule article.
Planned downtime	Y/N	If a service downtime is expected, specify its duration. The responsible person must fill in this field before the change request can be processed.
Downtime notes	Y/N	Add any notes about the planned service downtime. Fill in this field before the change request can be processed.
Possible conflicting changes	Y/N	Contains change requests that have a time overlap with this request. It possibly can impact request implementation. This field is populated automatically.
Actual start datetime	Y/N	Pick a date and time for the actual start of the request processing.
Actual end datetime	Y/N	Pick a date and time for the actual finish of the request processing.
Actual downtime	Y/N	If the service downtime occurs, specify its duration. This field is mandatory if the Planned downtime field is filled in, and the state of the change request is Completed.

* Whether the field is mandatory depends on the state of the change request.

Planning

To plan a change request, complete the following steps:

1. Navigate to Change Enablement → All Change Requests and open the change request you need.
2. On the Planning tab, describe the work plan for the phases.
3. Create the necessary tasks.
4. (optional) You can add created tasks into chains within a phase.

Planning phases

Phase	Mandatory*	Description
Preparation	Y/N	This plan specifies the steps that need to be done and the criteria to be met before implementing the change.
Core activities	Y/N	Describe the process of change implementation.
Validation	Y/N	The process of how the change must be tested after the implementation.
Rollback	Y/N	The plan specifies the processes that roll back the system, service, or CI condition to its previous state in case of a failed implementation.

* Whether the field is mandatory depends on the state of the change request and it repeats the behavior of the fields in earlier versions of the application. For example, when the state of the change request changes from Registered, the Work plan description fields become mandatory, tasks and chains in phases become read-only.

To track the process, each phase has a counter that displays the number of tasks completed and the total number of tasks in a particular phase. And in the right corner of the phase a badge is displayed that demonstrates the state of the work in the phase:

• When the change request and its tasks are In progress, the badge displays In progress. Until all tasks in the phases are completed, the state of the change request cannot be changed.
• Once all phase tasks are completed, the badge displays Completed.

To add tasks, complete the following steps:

1. In the necessary phase, click Add task.
2. Fill in the necessary fields. At this step, you can create a task chain by filling in the Previous task and Next task fields.
3. Click Save to apply the changes.
4. Repeat steps 1–3 to create the tasks in different phases.

After creation, each task has a context menu that allows you to:

• Add the task to the chain.
• Remove the task from the chain.
• Move the task to another phase.
• Cancel the task. When the task is canceled, it is moved to Canceled tasks, a separate group outside the phases. When the task returns back into a phase, the task state is set to Draft.

To view brief information about the task, click . You can also search through the list of tasks for different phases.

caution

change_manager can add task in all states of the change request except Authorization, Completed, and Closed.

Chains

---

Organize your work with change requests using chains. Chains in phases are numbered sequentially and they can be moved between phases like tasks. To move a chain to other phase, use the action.

To create a chain, complete the following steps:

1. In the context menu of a task, select Add to chain.
2. In the modal window that appears, specify the Previous and/or Next task.
3. Click Apply to save the changes.

When canceling or moving a task from a chain:

• the tasks that were previously associated with it are connected to each other if there are two or more tasks left in the chain.
• the chain is disconnected if there is only one task left in the chain.

The tasks that are not included in chains are stored in Other tasks, a separate group of the corresponding phase.

Change request authorization

Change requests of the non-standard type with Change authority not set to Local authorization must go through authorization procedure. For standard change request, the state changes to Scheduled automatically, without authorization.

The authorization is a request approval by change authorities of different levels, depending on the risk and probability levels. The higher the risk and probability levels are, the stricter the authorization procedure is.

In SimpleOne, once a change request requiring authorization is registered, it goes to the authorization stage. The state of the request changes to Authorization. For this, approval tickets should be sent to all necessary authorities, depending on the change authority level. In such a ticket, every recipient is prompted to approve or reject a request.

If all approval tickets have been approved, the change request is considered to be successfully approved. The state of the request changes to Scheduled.

If there is even a single approval ticket rejected, then:

• all other approval tickets are rejected automatically.
• the change request is considered to be rejected and goes back to the authorization stage.
• the state of the request is changed back to Registered.

For emergency changes, due to their high importance for business services or CI's, the relationship between the Registered and Authorization states is of one-way type. It means that emergency tickets cannot be rejected. Refer to the Change Types and State Models article to learn more.

Change authority level

---

caution

This role list is specified in the calculateCAB script include delivered with your solution. This script is intended for CAB automatic generation (except for Local authorization) for all authorities.

The following table shows the dependency between the change request risk level and the authority level.

Risk level	Change authority level
Low	Local authorization (authorization by the Assigned user)
Medium	Change manager only: All change managers
High	Basic CAB (Change Advisory Board): All change managers Service owner
Very high	Complex CAB (Change Advisory Board): All change managers All problem managers All incident managers All related CI owners Service owner

tip

• Change manager controls the lifecycle of all changes.
• The Change Advisory Board (CAB) group advises Change managers in prioritization, authorization, and scheduling changes.

Customize a CAB

---

A default CAB structure is described above, but you may need to modify it according to the organizational structure or business needs. You can do it in several ways:

• Modifying an script include containing parameters responsible for CAB gathering. These modifications will affect all change requests created later.
• Adding new participants to a specified change request CAB while processing it.

Modify a CAB script

---

tip

Role required: admin.

To bring in some global modifications into a default CAB, complete the steps below:

1. Navigate to System Settings → Script Includes.
2. Click the magnifier icon at the top of the list.
3. Enter calculateCAB into the Name field and press Enter; the relevant script should be found.
4. Click the script title to open it.
5. All role sets for different CABs are defined in this script with a corresponding comment, as follows:

// Complex CAB const roles = [ 'change_manager', 'problem_manager', 'incident_manager' ];

Add or delete a role into an appropriate section to modify any CAB, basic or complex.

For example, you want request managers to participate in a complex CAB, and, at the same time, you want to relieve problem managers from these duties. Then you need to delete the problem_manager role from the script and add the request_manager role.

tip

Note that this approval process works when these roles are applied to employees. It is not enough to create a user record and grant it a role; a relevant employee record must also exist.

Modify a specified CAB

---

You can also modify a CAB for any specified change request with no effect to further requests. For example, you want a particular change request to be approved by some specified employees.

• A CAB can be customized for change requests in the Registered or Authorization state.
• For change requests in the Authorization state, when a necessary user is added to the CAB and the change request is saved, an approval ticket is automatically sent to that user.
• The Customize CAB widget allows to add users with the ITSM_agent role.
• The users are added as mandatory participants of the approval process.
• The Ignore automatically generated CAB option allows for overriding CAB participants, designated by the included script described above, with those chosen from the list. This option is only available for change requests in the Registered state.

To customize a CAB, complete the steps below:

1. Navigate to the change request to extend.
2. Ensure that State IS Registered or Authorization and Change type IS NOT Standard.
3. Select the General tab.
4. Click the Customize CAB button and select the necessary users from the list (you can select as many users as you need).
5. Click Add.

Closure information

Based on the state model, the change request has to be closed when it has been fully processed. The Closure Information tab appears and becomes mandatory when the change request state is Completed, Post implementation review, or Closed

Field	Mandatory	Description
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: Implemented – The change request has been fully implemented. Partially implemented – The change request has been implemented with some exclusions that do not affect the critical functionality of the service. Not implemented (Rollback) – The implementation of a change request was not successful, and the previous state of service or CI was restored. Not implemented (Canceled) – The change request was cancelled because the change authority (CAB) authorization failed or was revoked.