Problem form details

The following table identifies and describes some of the features of problem forms:

Problem form details

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:

  • Problem Logging
  • Problem Categorization

  • Problem Investigation

  • Problem Resolution

  • Problem Review

  • Problem Closure

  • Problem Abandonment

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:

  • Open — The problem has been opened, but it is not currently being worked on.
  • Categorize — The problem is being categorized.
  • Assign — The problem is being assigned to the appropriate resource.
  • Work In Progress — The problem is being addressed.
  • Pending — The problem is pending for a period of time. The Problem Coordinator has contacted the vendor for information or for a part, or the Problem Coordinator has contacted the user for more information.
  • Deferred — Because of several possible constraints, the resolution of this problem must be postponed.
  • Resolved — A permanent fix is identified, and the problem is resolved.
  • Closed — The problem is closed or canceled.
  • Abandoned — The problem is abandoned (this only occurs in the Abandonment phase).

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:

  • 1 - Enterprise
  • 2 - Site/Dept
  • 3 - Multiple Users
  • 4 - User

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:

  • 1 - User
  • 2 - Group
  • 3 - Event
  • 4 - Chat
  • 5 - Email
  • 6 - Telephone
  • 7 - Incident
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:

  • Application
  • Email / Webmail
  • Field Support
  • Hardware
  • Intranet / Internet Support
  • Network
  • Office Supplies
  • Office Support
  • Operating System Support
  • SAP Support
  • Service Desk
  • Incident Manager

  • Problem Coordinators

  • Problem Managers

  • Service Manager

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:

  • Task ID
  • Status
  • Phase
  • Priority
  • Title
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 Incidents
  • Caused Changes
  • Solved By Changes
  • Related Problems
  • Related Known Errors

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:

  • ID
  • (Relation) Type
  • Phase
  • Status
  • Title
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.