Processing Change Requests

Assigning and Updating Change Requests

To assign a change request, perform the following steps:

1. Navigate to Change Enablement → All Change Requests and open a change request you need to assign.
2. Click the magnifier icon next to the Assigned User or the 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 a change request you need update.
2. Update the necessary fields.
3. Click Save or Save and Exit to apply changes.

All activities will be shown in the Note tab of the change request. 

Planning and Scheduling

Implementation of change request must be planned and scheduled carefully. Planning and scheduling allow minimizing vital business function disruption.

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

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. Open the Schedule tab, and 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.

To plan a change request, fill in the following fields in the Planning tab:

Change Request Authorization

The change requests that are not standard type must go through authorization procedure (the standard change state changes to the Scheduled automatically, without authorization stage).

The authorization is a request approval by Change Authorities of different levels depending on the risk level and probability level. The higher the risk and probability levels, the stricter the authorization procedure.

In SimpleOne, once a change request requiring authorization is registered, it goes to the authorization stage. The state of the request changes to the 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 proposed 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 changed to the Scheduled.

If there is even one approval ticket rejected, then:

• all other approval tickets must have been rejected automatically too
• 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 the 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 Enablement State Model article to learn more.

Change Authority level

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

Customizing a CAB

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

• Modifying an include script 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.

Modifying a CAB script

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

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

 // 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 the 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.

Modifying 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. Make sure 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.

Change Templates

You can create a template that can be used later to create change requests with predefined tasks. In addition, the templates make the processes easier by populating the fields automatically.

You can create a template of any complexity, prefilling any fields, including assignments. A template can be nested, so you can include change tasks into it if necessary.

Templates can be created in two ways:

• from scratch
• from the change request processed earlier.

Templates can be created for Standard or Normal changes. The difference between the two options is that a standard change template is already authorized. So any standard change request created out of the change template does not go through the authorization stage. And both the normal change template and its change request will be created with the Authorization state.

To create a change template from scratch, complete the steps below:

1. Navigate to Change Enablement → Change Request Templates.
2. Click New and fill in the fields.
3. Click Save or Save and Exit to apply the changes.

Change template form fields

Change template state model

The following picture describes the state flow of change templates:

In the following table, you can see state descriptions and available transitions.

Creating a template out of a change request

To create a template out of a change request, complete the following steps:

1. Navigate to Change Enablement → Closed and open the change request you need.
2. In the hamburger menu , select the Create Template item.
3. Edit the change request template form. 
4. Click Save or Save and Exit.

As a result, created template appears in the Change Request Template table and inherits all attributes from the parent record. That means, for example, if the request had some change tasks, the newly created template would have relevant related change tasks templates. The template will have a reference to the change request on the base of which it was created in the Created From Change Request field.

Template Approval Procedure

By default, template approval procedure is disabled. To enable it, activate the rule of approval for the table Change Request Template. 

Assignment of the responsible users for the template approval happens automatically when setting a rule of approval.

If a Change Template is created from a change, the CAB participants take part in the approval process. The templates created “from scratch” should be approved by all the users with the change_manager role.

See Approval Management for more information.

Closure Information

Based on the SimpleOne state model, the change request has to be closed, when it has been fully processed. The responsible person can provide the closure code, when closing the change request.

Closure code

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