Problem Workflow

The following figure shows the high-level Problem process workflow in the OOTB system.

Problem Workflow

1	Creator enters a Title, Detailed Description, Categorization, and Priority. When saved, the Problem is displayed on the Problem Management Dashboard to notify the Problem Management team of its existence.
2	Owner uses the Publish Known Error to Customer Portal Action. A One-Step Action posts the Diagnosis Field contents in the Known Errors section of the Portal.
3	Owner provides details of the Diagnosis and Workaround by submitting a Knowledge Article (KA), publishing in Portal, and/or emailing Customers. A One-Step Action creates a new KA using text from multiple Problem Fields. Text from the Workaround field is posted in the Top Issues section of the Portal. A One-Step Action sends a notification email to the Customers of linked Incidents.
4	A One-Step Action changes the status to Pending Change and creates a new Change Request record.
5	A One-Step Action makes the current User the owner, changes the Problem status to Resolved, and notifies Customers of linked Incidents.
6	A One-Step Action changes the Problem status to Resolved and sends an email to Incident owners (linked to the Problem) to notify them of the solution.

Note:CSM uses several features to manage the Problem workflow (example: the Problem Form helps create and manage Problems, One-Step Actions help move the Problem through its workflow, Automation Processes notify stakeholders via emails, a Problem Dashboard notifies stakeholders and tracks metrics, etc.).

Contributors

A Problem typically involves the following contributors:

Creator: User who first logs the Problem. This is typically a member of the Problem Management Team.
Owner: User who manages the Problem. This is typically an IT manager who is a member of the Problem Management Team.

Phases:

The Problem workflow is divided into the following phases:

Classify: Creator logs a new Problem. Then, the creator identifies and classifies the Problem (Description, Service, Category, and Priority). The creator updates Customers via Twitter and links related Incidents to the record.
Investigate: Ownership is assigned. The owner begins work, investigates and analyzes the Problem, and then records a diagnosis. The owner updates Customers by publishing the Problem to the Portal, and then links Configuration Items (CIs).
Known Error: Owner develops and records the workaround. Then, the owner can update Users (by submitting a Knowledge Article to Knowledge Base) and Customers (by publishing a known error to Customer Portal, post to Twitter, or send email).
Resolve: Owner records resolution details and cause code. Then, the owner can escalate the Problem and/or log a Change Request required to solve the Problem (if necessary). The owner then resolves attached Incidents before resolving the Problem.
Closed: Owner closes the Problem.

Statuses

A Problem progressing through the workflow encounters the following statuses:

New: Problem is being logged, identified, and classified.
Assigned: Problem has been assigned to an owner.
Work in Progress: Problem is being diagnosed, investigated, and analyzed.
Pending Change: Problem process is on hold until a Change Request is implemented.
Resolved: Problem is resolved.
Closed: Problem is closed.
Note: Problem statuses do not align with Problem phases.