Problem rules

Problem rules

A problem rule watches the ticket stream and surfaces a candidate problem record when the same pattern repeats. Without rules, repeating issues hide in queue noise — three printers down at three schools across two days look like three unrelated incidents until someone notices.

Anatomy of a rule

• Trigger — usually time-based; rules tick every hour by default
• Pattern — what to look for: tag, subject keyword, asset model, custom-field value
• Window — how far back to scan
• Threshold — N tickets matching → flag
• Action — open a candidate problem record, notify a role, or both

Example rule: “If 3+ tickets in the last 7 days have the tag printer-error AND none of them are linked to an existing problem, open a candidate problem and notify the IT lead.”

Threshold tuning

Too low → noise. The IT lead gets pinged every time three people with similar passwords lock themselves out in the same week.

Too high → it never fires. By the time you cross the threshold, the human eye would have caught it anyway.

A good starting threshold is the count of tickets you’d notice manually before getting suspicious — usually 3-5 in a 7-14 day window.

What “candidate” means

The rule doesn’t auto-create a confirmed problem; it creates a candidate. A human (usually the dept lead) reviews and either confirms (it becomes a real problem record), dismisses (false positive), or merges (links to an existing problem).

Confirmation rates above 70% mean the rule is well-tuned. Below 30% means it’s noise; revisit the pattern.

When to add a rule

After the second time you find yourself wishing you’d caught a pattern earlier. Don’t add rules speculatively for things that might recur — wait for the recurrence and then write a rule that would have caught it.

Rule order

Rules run in the order on the index page. Earlier rules can flag tickets in a way that prevents later rules from re-flagging them — useful for hierarchies (broad rule → narrow rule).

For most trusts, the order doesn’t matter; rules are usually orthogonal.

Disabling

Don’t delete rules; toggle Active off. Deleted rules lose their history (when they fired, what they caught) which is useful for tuning.