Work Problem Tasks and close an investigation

Problem Tasks organize investigation or remediation across specialist teams. Their mandatory flag controls whether the parent Problem may close; it does not create an ordered chain of execution.

Before you start

Review the parent Problem and assigned tasks in ExpertHub → Problem Tasks or the Problem detail screen. A task has its own team/assignee, type, status, sequence, due date, results and completion code. Its team may differ from the parent Problem's team.

Steps

1. Create or open a task with a concrete investigation outcome, such as collecting logs, reproducing a fault or validating a workaround.
2. Assign the specialist team and individual where supported, set the due date and record the task's type and scope.
3. Mark the task blocking/mandatory when its completion is required for final Problem closure.
4. Record progress and results. If moving the task to Pending, supply the required Pending reason.
5. Mark finished task work Completed, rather than Closed. Use Cancelled when appropriate and preserve an understandable record of the outcome.
6. Before final Problem closure, confirm all mandatory tasks are Completed or Cancelled.
7. Confirm either a documented root cause is confirmed or a risk acceptance reason has been recorded.
8. Ensure any workaround marked available has been published, then choose the appropriate tenant-configured terminal Problem status.

Expected result

Task results support the investigation, and the Problem reaches a terminal state only when all closure requirements are met. If closure is refused, inspect those requirements rather than renaming statuses.

Mandatory does not mean sequential

The sequence field does not enforce Change Task-style predecessor blocking. A blocking Problem Task is mandatory for parent closure; other tasks do not automatically have to wait for it. Coordinate dependent work explicitly with the teams involved.

The three closure requirements

• Every blocking/mandatory Problem Task must be Completed or Cancelled.
• Either the root cause must be confirmed or a documented risk acceptance reason must exist.
• If a workaround is marked available, it must have been published.

All three conditions apply together. Where no workaround is marked available, the third condition does not require inventing one. Risk acceptance is an explicit decision about residual risk; it does not mean the technical issue was eliminated.

Resolved versus terminal

Your organisation defines Problem statuses. The system uses each status's open and terminal settings rather than its name. A non-open, non-terminal resolved state is distinct from terminal closure and its stronger requirements.

Important behaviour

Use Completed for completed Problem Tasks. Pending requires a reason. Task editing follows the task's own authorization, and completing tasks or linking a Change does not automatically confirm the cause, publish a workaround or close the parent Problem. Verify the technical outcome as part of your investigation and resolution decision.

Related guides