Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Words and Phrases
| Search for | Example | Results |
|---|---|---|
| A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
|
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Using Boolean Operators
| Search for | Operator | Example |
|---|---|---|
|
Two or more words in the same topic |
|
|
| Either word in a topic |
|
|
| Topics that do not contain a specific word or phrase |
|
|
| Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
| A combination of search types | ( ) parentheses |
|
Change Management form details
The following table identifies and describes some of the features on the Change Management forms.
|
Label |
Description |
|---|---|
|
Change ID |
This is a system-generated field assigned when the change is opened. |
| Change Model | A change model is a record that is used to predefine the contents of a specific type of Request for Change (RFC), including the information used to populate the RFC and the tasks that are needed to complete the change. When you open a change request using a change model, most of the necessary information is added to the change automatically. |
|
Phase |
This is a system-generated field that specifies the name of the current phase of the change. |
|
Approval Status |
This is a system-generated field that defines the global approval status for the change, not for a single approval. The system sets this field depending on current approvals and the approval type defined for the module. These approval statuses are available out-of-box:
|
|
Change Requester |
The name of the user requesting the change. This is a required field. This field includes a hover-over form that displays full name, telephone, and email address if available for the user requesting the change. |
|
Assignment Group |
The group assigned to work on the change. For a description of this field see the Assignment Group field description in the Incident Management form details section in Service Manager Processes and Best Practices as this field functions similarly. The out-of-box data consists of default assignment groups for use as examples of types of assignment groups. You may want to change the sample assignment groups to meet your own needs. These assignment groups are available out-of-box:
|
|
Change Coordinator |
The person responsible for coordinating the change implementation. Each Change Coordinator may belong to several assignment groups. Each group must have only one Change Coordinator. |
|
Service |
Specifies the service affected by the change. This is a system-generated field and is prepopulated when a change request is created from an interaction. This is a required field. |
|
Affected CI |
The list of Configuration Items (CIs) affected by the change. The system prepopulates this field when a change request is created from an incident or problem. Users can add additional CIs. This field includes a hover-over form that displays check boxes for Critical CI and Pending Change. |
|
Location |
Specifies the location for the change. The system prepopulates this field when the change is created by escalating an interaction. |
|
Title |
Provides a short description or a gist of the change. This is a required field. |
|
Description |
Provides a detailed description of the change. This is a required field. |
| Scope | Provides a detailed description of the change scope. |
|
Category |
This is a system-generated field that classifies the type of change. |
|
Impact |
This field is prepopulated with data from an incident when a change is created from an incident. It specifies the impact the problem has on the business. The impact and the urgency are used to calculate the priority. These impacts are available out-of-box:
The out-of-box data is the same as Interaction Management, Problem Management, and Incident Management. This is a required field. |
|
Urgency |
The urgency indicates how pressing the change is for the organization. The urgency and the impact are used to calculate the priority. This field functions similarly to the same field for interaction, incident, and problem tickets. For more information, see User Interaction Management form details in Service Manager Processes and Best Practices. This is a required field. |
|
Priority |
This is a system-generated field using the urgency and impact of the change. This field functions similarly to the same field for interaction, incident, and problem tickets. For additional information, see User Interaction Management form details in Service Manager Processes Processes and Best Practices. |
|
Risk Assessment |
Specifies a code that indicates the risk incurred with the implementation of the change. This field becomes required in the Change Plan and Schedule phase. These risk assessments are available out-of-box:
After a user selects this field, the change may require additional approvals based on the risk. The approval is based on the risk number in the assessment approval record. This is a required field. |
| Financial Impact |
Specifies a code that indicates the financial impact of the change. These financial impact codes are available out-of-box:
|
| Review Required |
This option specifies whether post-implementation review is required or not. By default, it is set to true for Emergency and Normal changes in the Risk and Impact Analysis phase, while false for Standard changes in the Plan and Schedule phase. This field cannot be changed in subsequent phases. |
|
Requested End Date |
The system prepopulates this field if the change request is triggered from an interaction. This is the date the change initiator requests the change implementation. This is a required field if not prepopulated. |
|
Alert Stage |
This is a system-generated field that lists the current Alert Stage of this request. Change Management updates this field automatically when processing alerts against this change. Do not update it manually. The alerts are processed against a change by using the phase definition. This field is not active in an out-of-box system and must be manually enabled. |
|
Scheduled Implementation Start |
This field specifies the date and time that the work to implement the change should start. This field becomes required in the Plan and Schedule phase. |
|
Scheduled Implementation End |
This field specifies the date and time that the work to implement the change should end. This field becomes required in the Plan and Schedule phase. |
|
Scheduled Downtime Start |
The date and time when the change is scheduled to begin. Scheduled downtime only needs to be filled when the service is down, while implementing the change. |
|
Scheduled Downtime End |
The date and time when the change is scheduled to end. Scheduled downtime only needs to be filled when the service is down, while implementing the change. |
|
Configuration Item(s) Down |
If selected (set to true), indicates that the Configuration Items (CIs) are currently not operational and the downtime is scheduled. The fields Scheduled Downtime Start and Scheduled Downtime End are used along with the field Configuration Item(s) Down to indicate the scheduled time to bring the CI down. These fields are never required and should only be populated if you plan to bring down the CIs as part of the change. The interval selected applies to all the CIs of the change and cannot be specified by individual CI. When the change is closed, you may get the form confirming the outage times, and when you close the change, the CIs will be set as Up in Configuration Management. |
|
Ex. Project Ref. |
This field references an external project number. |
|
Implementation Plan |
An assessment of the change, often generated by the Change Implementer, that the Change Coordinator uses to assess the impact of the change to services. |
|
Effect of not Implementing |
The impact if not implementing the change. This is a required field. |
|
Change Owner |
The name of the user owning the change. This is a required field. |
|
Subcategory |
The subcategory is a breakdown of the category and describes the type of change in more detail. |
|
Actual Implementation Start |
The time when the implementation actually began. |
|
Actual Implementation End |
The time when the implementation actually ended. |
|
Review Results |
Results of the review after Post Implementation Review, this is a required field. |
|
Closure Code |
The completion code indicates the way a change is closed. VALID VALUES
|
|
Associated CIs section > CMDB attributes need to be changed for CIs in the list Completed/Cancelled CMDB attributes modifications CMDB relationships need to be changed for CIs in the list Completed/Cancelled CMDB relationships modifications |
The data in this section is used by the UCMDB integration whenever there are past changes to the values registered for the CI. |
|
Affected Services section > Affected Services |
This provides a list of affected services. When a configuration item for an incident is added or updated, a schedule record is created that runs a routine to update the list of affected services. |
|
Approvals section> Current Approvals |
This section provides an overview of the current approvals related to any changes for the CI, and important information such as approval status, and approvers as well. This includes a list of groups or operators who must acknowledge or accept the risk, cost, and so on associated with the implementation of a Change request or task. Approvals give controlling authorities the ability to stop work and to control when certain work activities can proceed. The data displayed includes the following information:
|
|
Approvals section> Approval Log |
This subsection provides an overview of past approvals related to the changes for the CI, as well as important information such as approval status and approvers. The data displayed includes the following information:
|
|
Reason for Change |
A code that indicates the primary reason for implementing the request. Examples of reason codes are Incident/Problem Resolution and Business Requirement. |
|
Approval section > Pending Reviews |
The name(s) of the groups or operator IDs that should review the change for the CI after it has been approved. |
| Cost section > Total Cost | This field indicates the system-calculated total cost of the Change, which is accumulated by the parts and labor cost of the Change itself and its related Change tasks. |
| Cost section > Currency | Specifies a currency code used by the system to calculate the total cost. |
| Cost section > Parts table | Specifies the parts used by the Change with their part numbers from the product catalog and the quantity used. |
| Cost section > Labor table | Specifies the technician who worked on the Change and the actual working hours. |
|
Tasks |
Whenever a change is in a phase where the user can generate tasks, Service Manager allows user a quick view of some of the most important fields in the task in the Tasks section. The data displayed includes the following information:
|
| Remediation Method | Indicates the remediation method: Full, or Partial. |
|
Remediation Comments |
Provides a detailed method for backing out the change if there is a problem implementing the change. This is a required entry for all changes while backing out a change. It is also required in the "Release back out" phase and for the Release Management category in order to close the "Release plan and design" phase. |
