Problem records

Problem records

A problem record captures the underlying cause of repeating tickets. It exists to track the investigation and the fix; once closed, hopefully no more incidents on this theme show up.

When to raise one

• Three or more tickets in the last 30 days describing the same symptom
• A single, large incident that affected a lot of people (postmortem)
• A vendor-side issue that you’re tracking from your end while waiting

A problem isn’t a bigger ticket; it’s an investigation. Don’t raise one just because a single ticket is annoying.

The lifecycle

State	What’s happening
Open	Raised but investigation hasn’t started yet
Investigating	We’re trying to figure out the root cause
Known error	We know what’s broken but don’t have a fix yet
Resolved	Fix applied; no recurrence expected
Closed	Resolved + reviewed; archived

A problem can sit in Known error for months — that’s fine, as long as the workaround is documented in the Workaround field and shared with the agent team. Note that “Workaround” is a text field on the problem record, not a lifecycle status of its own.

Linking incidents

The problem record’s Linked tickets section shows every ticket associated with it. Tickets are linked via the API or by an admin rule (see admin → Problem rules) that auto-associates matching tickets. Closing the problem can be configured to bulk-update linked incidents via Problem rules.

The link is visible from the problem record so you can see the full scope of the issue at a glance.

Workarounds

Document the workaround clearly inside the problem record:

• What does the user see?
• What’s the temporary fix?
• How long does it last?
• When should they ask again?

Then turn that workaround into a knowledge base article with audience=requester so the next person hitting the issue self-serves.

Root cause

The root cause section is where you write up the actual reason this kept happening. It’s the most-skipped section and the most-valuable. A problem with no root cause section becomes a half-remembered fix six months later when it returns.

A good root cause:

• Names the underlying mechanism, not just the symptom
• Identifies the trigger (what made it happen this time vs not)
• States what changed in the environment that exposed it
• Is short — one paragraph is usually enough

Problem rules (admin-configured)

Admins can set rules for auto-creating problems when N similar tickets land in a window. See admin → Problem rules. The rules don’t replace human judgment but they do flag patterns you might miss in the queue noise.