Ctrl+K
tatersecurity.com Open App

Problem Management

ITIL Problem records — root cause, workaround, and the Known Error Database — sitting behind the incidents they explain. Last updated 2026-07-26

What it is

An Incident is "the printer is down again." A Problem is "the print spooler leaks handles after a driver update, and that is why the printer keeps going down." Problem Management is where that second thing lives, so the underlying cause gets investigated on its own timeline instead of being re-diagnosed inside every ticket.

A Problem record carries the root cause, a workaround the help desk can apply today, the incidents it explains, and the configuration items it affects. Once it has a usable workaround you publish it as a Known Error, and it starts surfacing automatically to technicians working matching tickets.

The page is TATER Ops → Service Management → Problem Management.

Licensing

Problem Management requires a TATER Security product license and the Service Management (ITSM) module, which is a billable add-on. Without the module every /api/problems call is rejected, so the page and the MCP tools return nothing. Module entitlements are managed in TATER Manage.

The Problem record

FieldWhat it is for
Title (required)The cause, stated plainly. Max 500 characters.
DescriptionSymptoms, scope, and what you have observed. Max 10,000 characters.
StatusOpen, Investigating, Known Error, Resolved, or Closed. See the lifecycle below.
PriorityLow, Medium, High, or Critical. Defaults to Medium.
Root causeThe identified or suspected underlying cause. Max 10,000 characters. Empty is fine early on — that is what Investigating means.
WorkaroundThe temporary fix the help desk can apply now. This is the field that makes a Known Error worth publishing. Max 10,000 characters.
Publish as Known Error (KEDB)Checkbox. Ticking it — or setting the status to Known Error — puts the record in the Known Error Database.
Assigned toThe problem owner (name or email). Problems are long-lived; give one a name or it drifts.
Linked incident IDsThe Ops task / Major Incident ids this problem explains. One per line, up to 100.
Affected configuration itemsCMDB configuration-item ids, one per line, up to 100.

Lifecycle

  1. Open — a cause has been suspected and recorded, but nobody is on it yet.
  2. Investigating — someone owns it and is working the root cause. Fill in Root cause as the picture firms up.
  3. Known Error — the cause is understood well enough to publish, and there is a workaround. This status implies the Known-Error flag; you do not need to tick the box as well.
  4. Resolved — the underlying cause has actually been fixed (patch shipped, config corrected, vendor replaced the part).
  5. Closed — the fix has been confirmed in production and the record is done.

Moving a record to Resolved or Closed stamps a resolvedAt timestamp once; moving it back out clears it, so re-opening a problem that turned out not to be fixed does not leave a false resolution date behind.

Don't confuse this with the ITIL Problem task profile

TATER ships an ITIL Problem process profile for Ops tasks, whose flow (New → Assigned → Investigating → Known Error → Resolved → Closed) reads almost identically. That profile shapes a task: fields, allowed transitions, SLA defaults. This page is a separate Problem record in its own register, with its own KEDB. Use the task profile to run the investigation as assignable work; use the Problem record as the durable statement of cause and workaround. They are complementary, not alternatives.

Promoting a recurring incident to a Problem

There is no one-click "promote" button — a Problem is deliberately its own record with its own owner. The working pattern is:

  1. Notice the repeat. The new-ticket title box already shows possible duplicate tickets as you type, which is usually where a pattern first becomes visible.
  2. Click + New Problem on the Problem Management page and describe the cause, not the symptom.
  3. Paste the ids of the tickets it explains into Linked incident IDs — one per line. Major Incident ids go in the same list.
  4. Add the CMDB ids of what it affects under Affected configuration items, so the impact is visible from the CI side too.
  5. As soon as you have any workaround, tick Publish as Known Error. A half-understood cause with a working workaround is more valuable published than perfect and private.

Linking is authoritative from the Problem side — the Linked incident IDs list is what the UI edits and what the Connected panel reads. ITIL Incident tasks also carry a reverse linkedProblemId field, but it is settable through the REST API only and is not surfaced in the Ops task form today.

The Connected panel on a Problem's detail view shows the same cross-module relationships TATER draws elsewhere, so you can walk from a problem to its incidents, CIs, and related records without leaving the modal.

The Known Error Database (KEDB)

A Known Error is any Problem with the flag set or the Known Error status. Publishing one is not filing it away — it changes what technicians see while they work:

  • On the ticket. The Related knowledge panel on a task scores every Known Error against the ticket's text and shows the top few, each with the first line of its workaround, badged Known Error. A tech resolving a matching ticket is handed the workaround without searching for it.
  • While the ticket is being written. The new-task title box matches what you type against Known Error titles and descriptions and offers them inline, alongside possible duplicate tickets — so a known issue can be answered before the ticket is even filed.
  • On the module dashboard. The Service Management module shows a live Known Errors count that links straight to the filtered list.

On the Problem Management page itself, filter by status or tick Known Errors only (KEDB) to see just the published set — this is the view to review periodically, because a Known Error whose underlying fix has shipped should be moved to Resolved rather than left advertising a workaround nobody needs.

Write the workaround for the person on the phone

Known-Error matching is text-based, and only the opening of the workaround is shown in the ticket panel. Lead with the action ("Restart the Print Spooler service, then reprint"), and put the vendor case number and the long explanation in the description. Naming the symptom in the title and description also makes the record findable — the matcher reads title, description, root cause, and workaround.

MCP tools (4)

  • list_problems (Auditor+) — browse the register; filter by status or known_error_only. Use it to check whether a problem already exists for an incident pattern before creating a second one.
  • get_problem (Auditor+) — one record in full, including root cause, workaround, linked incidents, and affected CIs.
  • create_problem (Admin) — log a new problem. Accepts root_cause, workaround, is_known_error, linked_incident_ids, affected_cis, assigned_to.
  • update_problem (Admin) — patch in place; pass problem_id plus only the fields to change. This is how an agent records a root cause once identified, adds a workaround, or promotes a record to Known Error.

Every write is audit-logged as entity type problem and appears in the platform Activity Log with the calling identity.

Roles

  • Auditor and above — view the register and open any problem.
  • Admin — create, edit, publish as Known Error, and delete.

Deleting a problem removes only the problem record; the incidents and configuration items it linked to are untouched. Prefer Closed over delete — a closed problem is still searchable history, a deleted one is not.

Was this page helpful?