Create and assign a Problem

Use a Problem to investigate the underlying cause of recurring or significant incidents, prevent recurrence and decide how to manage unresolved risk. Incident Management restores service; Problem Management can continue investigating after that restoration.

Before you start

Work in ExpertHub → Problems. Check related Incidents and any existing investigation before creating another record. ITSM Lite supports Service and Offering context; CSM Full adds configuration-connected investigation where Configuration Management and permissions allow.

Steps

1. Open Problems and select the action to create a new Problem.
2. Enter an informative title and description of the recurring or significant issue, including observed symptoms and business effects.
3. Select the relevant Service and Service Offering where appropriate.
4. Assign the responsible team and coordinator as supported by the form.
5. Select the Problem type and source that explain how the issue was discovered.
6. Add known related Incidents and relevant CIs where applicable.
7. Save and note the generated PRB reference. The initial status comes from your organisation's configured Problem lifecycle.
8. Review the investigation scope and assign specialist Problem Tasks as needed.

Expected result

The Problem is a separate investigation record with clear service context and ownership. Its existence does not establish that a suspected cause has been confirmed.

Create from a candidate

A Problem Manager or administrator can promote a Pending Problem Candidate instead of creating a Problem directly. Review evidence before promotion; it creates a new Problem and links the candidate's grouped Incidents. The candidate remains a historical record. A manual candidate can be promoted with no incident links.

Primary CI and root-cause CI

A Primary or affected CI identifies a component associated with symptoms. A root-cause CI identifies the component determined to be responsible after investigation. Repeated incidents against one Primary CI are evidence for investigation, not proof that the CI is faulty.

Recording a root-cause CI can assert root-cause confirmation through the update workflow. Do not use it to store a speculative component: confirm the evidence before making that assertion.

Ownership and permissions

Administrators, Problem Managers and Incident Managers have broad Problem editing rights, subject to action-specific guards. Elevated users generally edit the Problem and worknotes only while members of its assigned team. Problem Tasks have their own team-level permissions, allowing another specialist team to contribute.

Important behaviour

Ordinary end users do not automatically have full Problem editing rights. Assigning a team does not confirm a cause. Linking a corrective Change preserves traceability but does not close the Problem or bypass the Change's separate approval, scheduling and execution rules.

Related guides