Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The Change Requests table is used for Change Management. A Change change request is created when a change is needed to a configuration item or to any other business object that may require a set of approvals before such a change can be completed.

Once a change request (CR) is created, it can be assigned to the appropriate teams or individuals for one or many approvals, and may then be moved along in the process, from approval to scheduling, to action by staff members actually making the change, to completion, testing, and release.

Of course each organization has its own definition of types of change that may need to be managed in this way, but we have prepopulated pre-populated the service catalog with a list of common change types. You can easily add your own change categories and types to the services table. Change Requests requests differ from Service Requests service requests in that they are not visible by default to end users and typically follow a stricter set of procedures and approvals.

The Change Request table pulls its services from linked entries in the Services table. A user creating a change request chooses the higher level business service Business Service from a drop-down, and then sees all the active service offerings for that business service in a second drop-down list called Service Title. The default service categories available services for change requests can be seen in the Configuration Items table Service Portfolio (or by creating a CR record and opening the drop-down list). When the service is selected, several additional fields are pulled in with the service, including the number of approvals whether or not approvals and tasks are needed.

Image Removed

...

Screenshot of the Change Request screen, showing the common area fields and the Details tab with sections for Submitter Information, Service Information, and Request Details. Image Added

Creation of Change Requests and Initial Actions

Change Requests requests (CRs) may can be created directly created by technician users or may be created by conversion action button from a Service Request or a Problem , in which case they are record. When created with action buttons, the Change Request is linked back to the generating record.

End User Record Submission

By default, Change Requests change requests are not visible to end-users and cannot be created by them. This is defined by group permissions, and if you would like to allow end users to submit change requests, you can simply change the group permissions of the relevant groups to enable this and enable access to change requests in the end user interface.

Technician Record Submission

When a technician submits a Change Requestchange request, the Submitter submitter contact information fields automatically populate based on the details in his/her User the user's Person record. In the default setup, a request cannot be submitted on behalf of a user who has no user record in the system. However, the creator can select a different person as the submitter if needed.

The Change Request table pulls its services from linked entries in the Services Service Portfolio table.   A user creating a change request chooses the Business Service from a drop-down, and then sees all the active services that belong to that business service in a second drop-down list called Service. The default Business Services for change requests can be seen in the Configuration Items table (or by creating a CR record and opening the drop-down list).  When the service is selected, several additional fields are pulled in with the service, When the service is selected, several additional fields are pulled in with the service, including fields defining whether approvals are needed and the approval generation type. Users in the appropriate groups may be given permission to change modify the number of approvals needed for a particular change.

When a technician creates the CR he may they choose an assigned team and assigned person from the drop-down fields at the top of the screen. If he does not choose the team, The assigned team or person will be automatically set when the record is saved , the assigned team will be auto-populated based on the logic described belowif the user does not choose the assignees. New CRs are created in the Status status of Open by default. Once the main fields are filled in, the user navigates to the Configuration Items tab.   This allows the user to look up several one or more configuration items.   The CI’s CIs can be filtered by choosing a CI Type first and then clicking the Select Configuration Items lookup. 

As CIs are selected, important information can be seen in the view of the CI'sCIs, including their criticality and the diagram that shows their relationships with other CI's:.

Image Removed

Note that if no configuration items In the Change Request, a view of Configuration Items shows important details such as Criticality, Subtype, Status, and a link to the relationship diagram.Image Added

You must choose a Configuration Item, even if none are involved in the change request, you are still required to select one, because of the way tasks are managed in change requests.  We have created a “No CI Involved” configuration item record with the CI Type of None that can . A Configuration Item is required to facilitate task management and prevent system errors. The “No CI Involved” configuration item record, with the CI Type of None, should be used in this situation.  This will allow all task generation and other functionality to work as expected. Once the configuration items have been selected, to further process the change request, the user needs to click the Submit for Review button: This saves the change request (validating the required fields), sets some background fields that control visibility of the approval and task buttons, and sets the status to Pending Change Manager

Once the CIs are selected, the user clicks Submit for Review to save the change request and begin processing. When the change request is saved, the status changes to Pending Change Manager. In addition, required fields are validated and background fields are set to control visibility of approval and task buttons.

Automatic Assignment of New Requests

When a new Change Request change request is saved, it is automatically assigned to a team based on the values in three fields pulled from other tables (Rule: CR- All Creation Actions, Action: Assign Change Request). The related service has a Responsible Team associated with it and a field called "'Give Service Responsible Team Priority over CI Team" with ' with a Yes/No value. If a Configuration Item configuration item was identified for the request, then there is also a CI Responsible Team field that will be populated in the CR.

The current assignment logic is: if the Assigned Team is empty when created and the Change Request change request involves a specific configuration item (CI), then the request is assigned to the responsible team for that CI, unless the "'Give Service Responsible Team Priority over CI Team" is ' is set to Yes. In this case, or If no CI is defined, then it is assigned to the Responsible team Team for the Serviceservice. If there is no Responsible Team for the Serviceservice, then it is assigned to the Change Management Team.

Naturally, this logic may be changed to suit your organization. You can simply set a default value such as the Change Management Team or you may choose some other logic to use based on different fields. The current logic is implemented in the CR rule named "CR'Create: All Change Request Creation Actions" ' and the action named "'Assign change request" and may be modified there'.

Automatic Emails Sent upon Submission

If the status is not Closed Completed when saved, the rule named "CR- All Creation Actions" a rule will send the submitter an acknowledgement email and will also send an email to either the Assigned Person, if there is one, or to the Assigned Team.

Anchor

...

There are two fields that result in automatically notifying specified people or teams when the Status of the Change Request is changed to Approved, Scheduled, and Completed.  These are shown near the bottom of the main Details tab:

Image Removed

The change manager can look up specific teams or people and populate them into these fields, and when the Status changes to Approved, Scheduled, or Completed, the teams and/or users will receive a notification telling them of the new status and details about the request.  Here is an example of the email sent when a request is scheduled:

Image Removed

...

Most services linked to Change Requests require one or more approvals.  See the section on Approval Management for details about how to set up approval workflows and templates.

Many of the default approval workflows for change requests contain conditional approvals, which depend on the Change Type (i.e. Standard, Normal, Emergency, Change Proposal) and Change Category (Category 1 - Minor or Small, Category 2 - Significant or Medium, Category 3 - Major or Large), and other factors. The workflows are pre-defined within each service, and can be used to create Change Models and Standard Change Workflows. Each Service may have both a default Approval Workflow and a default Task Workflow.

In addition to being able to define Standard Change workflows and workflows for Change Proposals and other Change Models, further Processing Details that are pulled into the Change Request are also stored in the Service record, including the Responsible Team, Escalation Team (i.e. which team it should be escalated to if thresholds for escalation are met), the default Change Type, and any additional fields that should be shown for the Change Request based on that service. 

Managing the Approval Process

Change requests can use different approval methods, discussed in the Approvals for Change Requests section on the Service Catalog page.  Based on the approval method defined in the service record, approvals will typically be created and launched within the change request using buttons.

...

We have defined a standard ITIL default approval workflow called Default - conditional approvals based on type/category  with conditional approvals generated based on the combination of Change Category and Change Type. It is a good illustration of how conditional approvals can be set up.  It contains the following approval templates:

Image Removed

The result of this setup is to create the following approvals for the following combinations of Change Category and Change Type:

  • Minor change - Change Manager Approval only
  • Significant Change / Normal - CAB Approval only
  • Significant Change / Emergency - ECAB Approval only
  • Major Change / Normal - IT Executive Board, then CAB Approval
  • Major Change / Emergency - IT Executive Board, then ECAB Approval

Approval Creation and Processing

Once the request has been sent for review, if it was for a service that requires approvals, the change manager can review it and generate any needed approvals. Clicking the Generate Approval(s) button will generate the approvals based on the predefined approval workflow.  If the change request service allows ad hoc approvals, options will be available to generate additional approvals as needed.  Approvals are generated in a Status of Queued by default.  Once the approvals are generated, new buttons appear:

Image Removed

When the change manager is ready for the approval process to start, she clicks the Launch Approval Process button, which will set all approvals with the lowest step number to Pending Approval.  It will also update the Status of the Change Request to Pending Approval.

When an approval’s status is set to Pending Approval, the approval team and/or Approver are notified by email. Only the person identified as the approver will be permitted to approve or reject the approval. The approval process is controlled by the step numbers.  Approvals with the same step number value are launched at the same time, when the approvals with the next lower step number are completed. This is a different model than in the task workflows, in which the sequence field is not functional.  With approvals, the step number controls the process and there are no separate sequences or threads in the approval process.

Another way in which approval generation is different from the handling of tasks is that conditional approvals are not created at all unless their condition is met at the time of generating the approval.  Since these conditions generally depend on the meta data and fields in the change request, it is important to make any critical fields required to hold a value before getting to the point of generating approvals.  The Recheck Conditional Approvals button does allow the technician to recheck the condition, if after generating the first approvals, the meta data changes.  But it is best to ensure that any needed meta data is filled out first.

As the first approvals are completed, those with the next step number are set to Pending Approval and their assignees notified.  Any approval notes put into the approvals are copied up to the change request in the running All Approval Notes field. Two fields below the approvals table track the Number of Approvals Needed and the Number of Approvals Completed, and once those two numbers are equal and great than or equal to 1, the Status is changed to Approved and the Requester and the Change Management team are notified.

Creating Tasks for the CR

Tasks are created for the CR once any approvals are done.  The user must first enter the Change Window Start Time and Change Window End Time, so that the tasks can be scheduled to start on the start date:

Image Removed

Here the default task template is the one called Upgrade Windows OS.  Clicking the Generate Tasks button will generate one task for each of the selected CI’s.

...

processing_records
processing_records
Processing the Change Request

Most services linked to change requests require one or more approvals. See the section on Approval Management for details about how to set up approval workflows and templates.

Many of the default approval workflows for change requests contain conditional approvals, which depend on the Change Type (i.e. Standard, Normal, Emergency, Change Proposal) and Change Category (Category 1 - Minor or Small, Category 2 - Significant or Medium, Category 3 - Major or Large), and other factors. The workflows are predefined within each service, and can be used to create Change Models and Standard Change Workflows. Each service may have both a default Approval Workflow and a default Task Workflow.

In addition to being able to define standard change workflows and workflows for change proposals and other change models, further processing details that are pulled into the CR are also stored in the service record, including the Responsible Team, Escalation Team (i.e. which team it should be escalated to if thresholds for escalation are met), the default Change Type, and any additional fields that should be shown for the change request based on that service. 

Managing the Approval Process

Change requests can use different approval methods, discussed in the Approvals for Change Requests section on the Service Catalog page. Based on the approval method defined in the service record, approvals will typically be created and launched within the change request using buttons.

Anchor
defaultworkflow
defaultworkflow
Default Conditional Approval Workflow

We have defined a standard ITIL default approval workflow called Default - conditional approvals based on type/category with conditional approvals generated based on the combination of Change Category and Change Type. It is a good illustration of how conditional approvals can be set up. It contains the following approval templates: Change Manager Approval for all Minor changes; IT Executive Board Approval for Major Change; CAB first Approval for Significant Normal Change; ECAB First Approval for Significant Emergency Change; CAB second approval for Major/Normal change; ECAB second approval for Major / Emergency change.

The result of this setup is to create the following approvals for the following combinations of Change Category and Change Type:

  • Minor change - Change Manager Approval only
  • Significant Change / Normal - CAB Approval only
  • Significant Change / Emergency - ECAB Approval only
  • Major Change / Normal - IT Executive Board, then CAB Approval
  • Major Change / Emergency - IT Executive Board, then ECAB Approval

Approval Creation and Processing

Once the request has been sent for review, if it was for a service that requires approvals, the change manager can review it and generate any needed approvals. Clicking the Generate Approval(s) button will generate the approvals based on the predefined approval workflow. If the change request service allows ad hoc approvals, options will be available to generate additional approvals as needed. Approvals are generated in a status of Queued by default. Once the approvals are generated, new buttons appear to 'Launch Approval Process' and 'Recheck Conditional Approvals.'

When change managers are ready for the approval process to start, they click Launch Approval Process to set all approvals with the lowest step number to Pending Approval. It will also update the status of the change request to Pending Approval.

When an approval’s status is set to Pending Approval, the approval team and/or approver are notified by email. Only the person identified as the approver or on the approval team will be permitted to approve or reject the approval. The approval process sequence is controlled by the step numbers. Approvals with the same step number value are launched at the same time, when the approvals with the next lower step number are completed. This is a different model than in the task workflows, in which the prerequisite task functionality provides more sophisticated branching sequences. With approvals, the step number controls the process and there are no separate sequences or threads in the approval process.

Another way in which approval generation is different from the handling of tasks is that conditional approvals are not created at all unless their condition is met at the time of generating the approval. Since these conditions generally depend on the meta data and fields in the change request, it is important to make any critical fields required to hold a value before getting to the point of generating approvals. The Recheck Conditional Approvals button does allow the technician to recheck the condition, if after generating the first approvals, the meta data changes. But it is best to ensure that any needed meta data is filled out first.

As the first approvals are completed, those with the next step number are set to Pending Approval and their assignees notified. Any approval notes put into the approvals are copied up to the change request in the running All Approval Notes field. Two fields below the approvals table track the Number of Approvals Needed and the Number of Approvals Completed, and once those two numbers are equal and greater than or equal to 1, the status is changed to Approved and the Requester and the Change Management team are notified.

Managing Tasks 

Some services have predefined tasks that will be created, either in a multi-sequence workflow, or individually.

Tasks are generally created for the CR once any approvals are done. The user must first enter the Change Window Start Time and Change Window End Time, so that the tasks can be scheduled to start on the start date.

Image Added


Services with a Single Default Task Defined

Here is an example where there is one default task for a given service (Perform update to the selected configuration item). Clicking the Generate Tasks button will generate one task for each of the CIs listed in the Generate Tasks for field.


Image Added

The result of clicking the Generate Tasks button in this case is:

Image Added

Generating Ad Hoc Tasks

Depending on the options selected in the service, the user may have an option to create one or more than one ad hoc tasktasks.   He may also check the box for Create New Task to Generate? to create another task template that can be generated for all the selected CI’sCIs.   Checking that box will bring up some fields to fill in for the ad hoc task:

Image RemovedImage Added

Clicking the button to Create New Task to Generate will create a new Task Template, save the change request, and reopen it to edit, with the new task selected in the Task to Generate field.   From here, you he can click the Generate Tasks button again to add the Task to this CR for each CI that is selected.

Launching Tasks

Tasks may not be launched until the approval process is completed.   This is to ensure that no work is started without approval. Clicking the Launch Tasks button will run the following checks and actions:

  • If the field Service Approvals Required is set

...

  • to Yes and there are still pending approvals, the tasks are prevented from launching.
  • If the change request is related to a release and the release status has not yet advanced to Build in Progress or beyond, the tasks are also prevented from launching.
  • Otherwise, a background field that controls visibility of the Launch Tasks button is set to No, a field controlling visibility of the Create Tasks button is set to No, the field Launched in all tasks for the workflow is set to Yes, the tasks without prerequisites are set to a status of Assigned, and the change request status is set to Implementation Started.

See the Task Templates and Tasks Table topics above for more details on how tasks are launched and processed.

Reassigning the Change Request

If a technician needs to To reassign the Change Request change request to a different team or person, he or she simply changes change the Assigned Team and/or Assigned Person field and the system will email the new assignee notifying them of the reassignment. Rule: CR - Edit Actions (API Enabled), Action: Assignee Change Notifications.

Anchor
completion
completion
Completing the Change Request

When all tasks are completed, the Change Manager is notified.   Based on whether the tasks were all completed or whether some of them failed, the change manager will then set the Status status of the Change Request change request to Completed and the Closure Category to the appropriate value.   If there are tasks whose status is Failed, the closure category will be validated to contain an appropriate value.

Changing the status to Completed will send an email to the Requester informing him stating that the change is completed. Upon closing a change request, fields on the Progress Notes and Outcomes Work Status tab can be used to generate create a knowledge article Knowledge Article based on the change request.

Setting 'Review for Knowlegebase' to Yes indicates that a knowledge article will should be created considered based on this change request. Once Review for Knowledgebase is Yes, the Knowledge Document Status and Create Knowledge Article fields are visible.The default value of Knowledge Document Status is Pending Review, and once Create Knowledge Article is clicked, the Knowledge Document Status is automatically updated to Created. If it turns out the knowledge article is not necessary, Knowledge Document Status can be changed to Not Needed manually. Clicking Create Knowledge Article opens a new knowledge article record with some information mapped from the change request, such as the Title, Purpose, and Description. Additional required fields must be populated before saving the record. Once the new knowledge article is saved, it is automatically linked within the originating change request. In addition, the knowledge article will automatically include about the source change request.

Working Notes

The Work Notes field is updated from the running working notes for all of the related Tasks.

Related Records and Removing Tasks

During the working process, some tasks may be removed as not needed by the change manager.  The action bar above the Tasks table in the change request includes a button to remove one or more tasks. This changes the status of the selected tasks to Not Needed and they move into the Inactive Tasks table shown on the Inactive Tasks tab:

Image Removed

From this area, if it turns out that the task actually is needed, the change manager can select one or more tasks and click the Reassign Task to set their status to Assigned and move them back into the active Tasks tableinformation mapped from the change request, such as the Title, Purpose, and Description. Additional required fields must be populated before saving the record. Once the new knowledge article is saved, it is automatically linked within the originating change request. In addition, the knowledge article will automatically include about the source change request.

Working Notes

The Working Notes field is updated automatically from the running working notes for all of the related Tasks.

Related Records and Removing Tasks

During the working process, some tasks may be removed as not needed by the change manager. The action bar above the Tasks table in the change request includes a button to remove one or more tasks. This changes the status of the selected tasks to Not Needed and hides them. They are moved to the History tab and the embedded table called Inactive Tasks. There is a button above this table allowing the user to select a task and reassign it back to an active task.

Anchor
statusnotifications
statusnotifications

Additional Notifications to Teams and Individuals

There are two fields that result in automatically notifying specified people or teams when the status of the change request is changed to Approved, Scheduled, and Completed. The 'Notify these Teams on Status Changes' and 'Notify these People on Status Changes' fields are shown near the bottom of the Details tab.

Screenshot of two fields used to CC teams or people about a Change Request.Image Added

The change manager can look up specific teams or people and populate them into these fields, and when the status changes to Approved, Scheduled, or Completed, the teams and/or users will receive a notification telling them of the new status and details about the request. The following is an example of the email sent when a request is scheduled.

Panel

Subject: Change request 278 is Scheduled

Body: You are identified as a CC on the change request shown below, which has just been schedule.

The change is scheduled to start on Jul 05 2016 01:00 and to end at Jul 05 2016 03:00.

Click here to view the request directly.

ID: 278

Change Category: Category 2 - Significant or Medium

Status: Scheduled

Change Management Team: Change Management Team

Change Manager: Chuck Eisner

...

Parent/Child Relationship

Previously we used a parent-child relationship of change requests to manage changes to multiple CI’sCIs.   That possibility is still available but the fields for relating parent and child change requests have been removed from the layout, since that was a much more cumbersome process than the improved process based on generating tasks for each CI configuration item within the change request.   However, if there is a need to relate change requests in a parent child structure, this logic can be re-utilized by putting the fields back on the layout and enabling the rules that managed the relationships.

Reporting Time Spent

Technician users may easily report the time they spend on handling change requests. There are two fields and an action button: Time Spent, Time Description, and Add Time on the Work Notes tab of the layout. Entering values there will automatically create a new time entry record when the Add Time button is clicked. The time entry will show the work done by the technician and on the current date.

All the time entries for a request can be seen on the Time tab as well. If a technician needs to report time that was spent on a different day or by a different user, he may click the New button on the Time spent table to submit a time entry directly and change the date or "Done by" field. All time entered is totaled in the All Time Spent field, which can be used in reporting or billing.

Note that this same time entry methodology is used in the Incident, Problem, Service Request, and Task tables.

Workflow

Image Removed

...

This section contains an overview and screenshot examples of the information stored in a Change Request in the out-of-the-box system.

Details Tab

A Change Summary must be entered to briefly describe the change, and a Change Category must be selected to categorize the significance of the change. An Assigned Team and Assigned Person can be selected, and anyone who wants to be CC'd on all notifications can be added to the Internal CCs field. If an Assigned Team is chosen but an Assigned Person is not, all team members will receive a notification. If an Assigned Person is chosen, the email will be sent only to that individual.

The submitter fields, Submitter Name, Preferred Notification Method, Phone, Department, Service Level, and Service Catalog in the Submitter Information section default to the person who creates the Change Request, but this can be changed by clicking the lookup icon. 

Next, a Business Service must be selected. Depending on the Business Service chosen, certain Services are available to categorize the Change Request further. The Risk for both if the Change is done and not done can be logged for analysis and assessment of the overall risk of the Change Request. Impact indicates the scope of the Change Request's effect, and Urgency can be used to convey how important it is to make the change. Impact and Urgency have options that are available based on the Priority Group for the Service selected. Once Impact and Urgency values are selected, the Set Priority button can be clicked to calculate which Priority to use for the Change Request based on the Impact and Urgency.

A description of the Change is required, and in some cases, a business reasons that justify the change. A backout plan is required, and an attachment or multiple attachments with more details can also be uploaded.

...

The Configuration Items and SLA's tab shows all of the Configuration Items that will be affected by the change being requested, and allows the user to quickly create these relationships between the Change Request and the CIs. Any relationships created here will also subsequently be displayed when viewing the CI record directly. CI attributes are also shown to facilitate change assessment and authorization, such as the Criticality of each CI.

Image Removed

 

The Diagram column icon outlined above can be clicked to see a relationship diagram for each CI, showing the other CIs to which it is related:

Image Removed

Approvals

...

Image Removed

The Schedule and Tasks tab displays the Maintenance window for the Service and indicates whether or not there will be downtime. In addition, the Change Request can be tied to a Release record, and information about the Change Window Start Time and Change Window End Time can also be included. Once the change request is ready to be scheduled and has been approved, a button appears to create one or more calendar entries for the change window, as well as for any build or test activities that should be published in the change calendar.

If Tasks are required for the Change Request, they are also shown on this tab with a Default Task Workflow and the option to customize and generate tasks.

Progress Notes and Outcomes

Anchorprogress_notes_and_outcomesprogress_notes_and_outcomesThe Progress Notes and Outcomes tab provides a place for working notes to be added. If the Status is changed to a terminal status (i.e. Completed, Canceled, etc.), a Closure Category is also specified for the Change Request

Workflow

Image Added

Anchor
fields
fields
Change Request Form Layout

This section contains an overview and screenshot examples of the information stored in a change request in the out-of-the-box system.

Details Tab

A Change Summary must be entered to briefly describe the change, and a Change Category must be selected to categorize the significance of the change. A Change Management Team and Change Manager can be selected, and any team or people who want to be CC'd on status change notifications can be added to the notification fields. If a Change Management Team is chosen but a Change Manager is not, all team members will receive a notification. If a Change Manager is chosen, the email will be sent only to that individual.

The submitter fields, Submitter Name, Email, Phone, Manager, and Department in the Submitter Information section default to the person who creates the Change Request, but this can be changed by clicking the lookup icon. 

Next, a Business Service must be selected. Depending on the Business Service chosen, certain Services are available to categorize the Change Request further. The Risk for both if the Change is done and not done can be logged for analysis and assessment of the overall risk of the change request. Impact indicates the scope of the change request's effect, and Urgency can be used to convey how important it is to make the change. Impact and Urgency have options that are available based on the priority group for the service selected. Once Impact and Urgency values are selected, the Set Priority button can be clicked to preview the Priority that will be assigned to the Change Request based on the Impact and Urgency.

A description of the change is required, and in some cases, business reasons that justify the change. A backout plan is required, and an attachment or multiple attachments with more details can also be uploaded.

Anchor
cis
cis

Configuration Items Tab

The Configuration Items tab shows all of the configuration items that will be affected by the change being requested, and allows the user to create these relationships between the change request and the CIs. Any relationships created here will also subsequently be displayed when viewing the CI record directly. CI attributes are also shown to facilitate change assessment and authorization, such as the Criticality of each CI.

Screenshot of Configuration Items tab in the CR record, highlighting the Relationship Diagram column to the far right.Image Added

In the Relationship Diagram column, click the tree icon to see a relationship diagram for each CI that shows the other CIs to which it is related.

Relationship diagram of the Dell Optix computer for employee item, which is Contained by 'Network Data Center' and uses Windows 10, Brother 6180 Printer 3, and Samsung 48in Silver. Image Added

Approvals Tab

Anchor
fields_approvals
fields_approvals
Based on the requirements specified for the service that the change request pertains to, approvals may be required. The Approvals tab displays the default Approval Workflow for that Service, and a different one can be selected if needed using a lookup. The approvals are then generated and launched, with the first approval set to a status of Pending Approval. Once all approvals are completed, the status of the change request is set to Approved.

Anchor
schedule_and_tasks
schedule_and_tasks
Schedule and Tasks Tab

The Schedule and Tasks tab displays the maintenance window for the service and indicates whether there will be downtime. In addition, the change request can be tied linked to a Release record, and information about the Change Window Start Time and Change Window End Time can also be included. Once the change request is ready to be scheduled and has been approved, buttons appear to create one or more calendar entries for the change window, as well as for any build or test activities that should be published in the change calendar.

If Tasks are required for the change request, they are also shown on this tab with a Default Task Workflow and the option to customize and generate tasks.

Screenshot of Schedules and Tasks tab of the Change Request record.Image Added


Work Status Tab

Anchor
progress_notes_and_outcomes
progress_notes_and_outcomes
The Work Status tab provides a place for working notes to be added. If the status is changed to a terminal status, for instance Completed or Canceled, a Closure Category is also specified for the change request.

Time Tab

Technician users may easily report the time they spend on handling change requests. There are two fields and an action button: Time Spent, Time Description, and Add Time on the Time tab of the layout. Entering values there will automatically create a new time entry record when the Add Time button is clicked. The time entry will show the work done by the technician and on the current date.

All the time entries for a request can be seen on the Time tab as well. If technicians need to report time spent on a different day or by a different user, they may click New on the Time spent table to submit a time entry directly and change the date or Done by field. All time entered is totaled in the All Time Spent field, which can be used in reporting or billing.

Note that this same time entry methodology is used in the Incident, Problem, Service Request, and Task tables.

The Related Records tab displays all of the links/relationships to and from the Change Request, including related Problem problem records, related Incidentsincidents, Incidents incidents caused by the Change Requestchange request, and related Service Requestsservice requests

Ownership

Records in the Change Request change request table are " owned " by the person whose login matches the Creator Login field.

Reporting and Statistics

This section describes the reports and statistical functions in the Change Requests table. 

Anchor
forward_schedule_of_change
forward_schedule_of_change
Forward Schedule of Change and Projected Service Outage

The Forward Schedule of Change represents approved changes and the proposed implementation dates. More generally, it is a list of Change Requests change requests set to occur in the future. Functionally it might include CRs with restricted criteria, such as approved changes only, but by default the Forward Schedule of Change simply shows all Change Request change request that are not in a status of Closed.

The Forward Schedule of Change is a saved search available from the vertical navigation left pane menu under the Change Request table name. Change Requests are listed in order of Requested Date of CompletionChange Window Start Time. This search is also used in a structured HTML report of the same name. The report groups the CRs by requested date of completion (, by week) , and shows summary data , including the sum of the Estimated Time to Complete for all records. The report can be configured to be sent in a weekly email to the Change Management team.

Anchor
projected_service_outage_pso
projected_service_outage_pso
Projected Service Outage

The Projected Service Outage represents all approved changes that are set to occur in the future that will result in downtime. Similar to the Forward Schedule of Change, the Projected Service Outage (PSO) is also available from the vertical navigation menu under the Change Request table name, and can be viewed in a structured HTML report. The Change Requests in the PSO are listed in order of the Change Window Start Time. 

Both the Forward Schedule of Change and Projected Service Outage can be set up to automatically be emailed to various teams. This also applies to all Charts and Reports, which can be configured to be automatically sent to the defined teams. This allows for the sending of various reports to accommodate pre and post meeting workflows or CAB/eCAB proceedings, such as reports of pending changes, completed changes, and CRs pending post change reviews. 

Change Requests can also be easily added to the Change Schedule using the Calendar icon at the top right corner of any record. Users can also subscribe and add the calendar as an internet calendar in Outlook. Users can further refine what they see on their calendars based on the Event Type in the Calendar entries (i.e. Build, Test, Implementation, etc). A link can also be generated and the same link can be distributed to all users to integrate the schedule into their Outlook Calendars.

Image Removed

Accomplished Change

Accomplished Change is the complement to the Forward Schedule of Change and by default shows all closed Change Requests, sorted by Date Closed.

...

Description:  These actions are run when the button Launch tasks is clicked. If the field Service Approvals Required is set to Yes and there are pending service approvals, the tasks are prevented from launching. If the change request is related to a release and the release Status has not yet advanced to Build in progress or beyond, the tasks are also prevented from launching.

Otherwise, the change request Status is set to Scheduled, a background field that controls visibility of the Launch Tasks button is set to No, the field Launched in all tasks for the workflow is set to Yes, a field controlling visibility of the Create Tasks button is set to No, and the tasks without prerequisites are set to a Status of Assigned.

Image Removedleft pane menu under the Change Request table name, and can be viewed in a structured HTML report. The change requests in the PSO are listed in order of the Change Window Start Time. 

Both the Forward Schedule of Change and Projected Service Outage can be set up to be automatically emailed to various teams. This also applies to all charts and reports, which can be configured to be automatically sent to the defined teams. This allows for the sending of various reports to accommodate pre and post meeting workflows or CAB/eCAB proceedings, such as reports of pending changes, completed changes, and CRs pending post change reviews. 

Change requests can be added to the Change Schedule using the Calendar icon at the top right corner of any record. Users can also subscribe and add the calendar as an internet calendar in Outlook. Users can further refine what they see on their calendars based on the Event Type in the Calendar entries, for instance Build, Test, Implementation. A link can also be generated and the same link can be distributed to all users to integrate the schedule into their Outlook Calendars.

Calendar image showing appointments created by scheduling change requests in the system.Image Added

Accomplished Change

Accomplished Change is the complement to the Forward Schedule of Change and by default shows all closed Change Requests, sorted by Date Closed.