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.
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. |
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 |
|
Problem form details
The following table identifies and describes some of the features of problem forms:
Label |
Description |
---|---|
Problem ID |
Specifies the unique ID of the problem. This is a system-generated field. |
Title |
A short description that summarizes the problem. This field is pre-populated with data from an incident when a user opens a problem from the incident. This is a required field. |
Description |
A detailed description of the problem. This field is pre-populated with data from an incident when a user creates a problem from the incident. This is a required field. |
Affected Service |
Specifies the service that is affected by the problem. This field is pre-populated with data from an incident when a user opens a problem from the incident. For more information about this field, see the "Affected service" section of the table in Service Desk Interaction Management form details. This is a required field. |
Phase |
This is a system-generated field. The following phases are available out-of-box:
|
Status |
Specifies the status of the problem. This field may affect the phase of the problem. All status changes must be performed manually. When the status changes, the problem phase may change automatically. There are several reasons to change the status of a problem (for example, when you are waiting for information from a vendor). The following statuses are available out-of-box:
|
Category |
This field is pre-populated with the default category. If a default category is not defined, you must select a category before open a new problem form. The out-of-box data is only “problem”. The problem category can be shared by Service Desk or Incident categories. You can also define new categories according to your needs. |
Subcategory |
The second level of categorization. This field is pre-populated with data from an escalated incident. Service Manager displays different lists of subcategories, depending on the category that you selected. The subcategories are defined on a category. |
Area |
The third level of classification, mainly used for reporting purposes. This field is pre-populated with data from an escalated incident. Service Manager displays different lists of areas, depending on the category and subcategory that you selected. The areas are defined on a subcategory. |
Impact |
This field is pre-populated with data from an incident. It specifies the impact that the problem has on the business. The impact and the urgency are used to calculate the priority. The following impacts are available out-of-box:
The out-of-box data is the same as Interaction Management and Incident Management. |
Urgency |
This field is pre-populated with data from the incident. The urgency indicates how pressing the problem is for the organization. The urgency and the impact are used to calculate the priority. For more information about this field, see Service Desk Interaction Management form details. |
Major Problem |
If selected (set to true), it indicates the problem is a major problem, then the Problem Manager needs to specified and notified.
|
Major Problem Review section | This section is only visible when Major Problem is selected. Review details for this major problem can be documented under this section. |
Source |
The source from which the record is created. The following out-of-box sources are available:
|
Contact Person | This field is pre-populated with data from the interaction or incident when the problem is opened from an interaction or incident. It specified the contact person for the reported problem. |
Categorization > Priority |
The order in which to address this problem in relation to other problems. The priority value is calculated by using the initial impact and urgency. This field only appears when problems that are being updated or escalated from incidents. |
Categorization > Assignment Group |
The group that is assigned to work on the problem. For more information about this field, see Incident Management form details. The out-of-box data consists of default assignment groups for use as examples of types of assignment groups. Tip You may want to change the sample assignment groups to meet your own needs. The following assignment groups are available out-of-box:
This is a required field when status starts from Assign and phase starts from Categorization. |
Categorization > Assignee |
The name of the person who is assigned to work on this problem. If the Assignment Group field is filled in, the system will populate this field with the pre-defined Problem Coordinator for that group. This person can be changed to any other member of that group using the Fill function. The operator that you select should be a member of the Assignment Group. |
Workflow section | Displays a figure of the problem workflow. Also indicates the phase that the problem is currently in, and traces the phase transition history. |
Affected Configuration Items section > Primary CI |
Specifies the name of the failing Configuration Item (CI). The primary CI identifies the CI that causes the service to go down or become unavailable. The affected CIs in the related incidents and interactions are all of the CIs affected by the service. It is the primary CI that must be fixed to restore the service. For example, if a mail service goes down because of a disk error on the server, the mail server is the primary CI. Every CI that connects to the mail service (that is, that has Microsoft Outlook installed) is an affected CI. |
Affected Configuration Items section > Affected CIs’ table | The affected CIs are CIs that will have an issue when the primary CI has an issue. These fields must be filled in manually and are for information only. This data does not drive any action and is not required. |
Affected Configuration Items section > Affected CI Count |
A system-generated count of the number of CIs that are affected by the outage. The count does not include the primary CI. The affected CI count is based on the number of items entered in theAffected Configuration Items section.The affected CI count is calculated based on the Assessment section in the Affected CIs table. |
Tasks section |
The user can add tasks during any phase of a problem. Every task must be finished before the problem can be closed. To add a new task, click the Tasks section, and then click the Link New Task button. Service Manager provides users with a quick view of some of the most important fields in the task in the Tasks section. The data displayed includes the following information:
|
Related Records section > Link Type |
Specifies a relationship type between the problem and the target ticket. The following groups of link types are available out-of-box:
|
Related Records section > Link Existing/New Record button | After you select a link type, use these two buttons to associate the problem with a target ticket, or to create a new target ticket and associate it with this problem. |
Related Records section > All Related Records table |
Displays information on all the records that are related to this problem. The data displayed includes the following information:
|
Related Records section > Duplicate of Problem | Verifies whether this problem is a duplicate of another problem. If the problem is a duplicate, enter the duplicate problem ID in this field. Then, manually close the problem by clicking More > Close Duplicate Problem. |
Related Records section > Duplicate Problems | Identifies problems that are duplicates of this problem. This field can be populated manually, or automatically, when other problems are verified as duplicates of this problem. |
Related Records section > Related Incident Count | This is a system-generated field. The related incident count is the number of incidents that are related to the problem, as recorded in the screlation table. To relate an incident to a problem, click the Related Records section, select Link Type as Related Records, and then click the Link Existing Record button. |
Investigation and Resolution section > Expected Resolution Date | The expected problem resolution date should be approximately the same as the SLT Target date. The expected problem resolution date is the date when you plan to close the record. This should be done before the SLT Target date. This field has the Problem Management past due alert attached to it. This field appears when the problem enters Investigation phase. It becomes a required field in the “Work In Progress” and “Investigation” phases. |
Investigation and Resolution section > Expected Root Cause Identified Date |
Specifies the date by which the identification of the root cause of the problem is expected. You should base the date on the target date and on the identified dates in the SLT. This field appears in the “Investigation” phase to assist prioritization and planning in problem management processing. The field becomes a required field when the status changes to “Work In Progress” and the phase changes to “Investigation”. |
Investigation and Resolution section > Solution Identified Date | The date when you identify the solution. This field appears when the problem enters the “Investigation” phase, and becomes required when the status changes to “Resolved”. |
Investigation and Resolution > Root Cause | A detailed description of the cause of the problem. You cannot move on from the Problem Investigation phase until you have entered a description in this field. That phase is not complete until the cause of the problem is known. |
Investigation and Resolution > Workaround | Describes a temporary solution or workaround. |
Investigation and Resolution section > Estimated Man Days | Specifies a resource estimate to diagnose and resolve the problem. This data does not drive any action and is not required. |
Investigation and Resolution > Estimated Cost | Provides a resource (cost) estimate to diagnose and resolve the problem. This data does not drive any action and is not required. |
Investigation and Resolution > Solution | Describes a permanent solution to the problem. This field is required when the problem status changes to “Resolved”. |
Closure Code | Uses a pre-defined closure code to specify the way in which the problem was closed. The out-of-box data is defined in the probcause table. This field is required when a problem is closed or abandoned. This field is populated in the closure wizard, and then automatically populated in the Summary section of the problem form. |
Closure Comments | Comments to close the problem. This field is populated in the closure wizard, and then automatically populated in the Summary section of the problem form. |
Cost section | The user can add cost details of parts and labor for this incident handling. For more information about this field, see Incident Management form details. |