In ITIL vocabulary, a Known Error is a Problem that has been diagnosed but not yet permanently fixed — usually because the fix is expensive, blocked on a vendor, or queued behind something else. The valuable thing about a Known Error is the second half of the record: you know what causes it, and you know what to do until the real fix lands. Captured properly, that knowledge turns a 30-minute investigation by L1 into a two-minute lookup-and-apply. Lost or scattered, it becomes the same five technicians independently rediscovering the same workaround every month.
The Problem module is where it lives in GLPI
Open Assistance > Problems. A Problem in GLPI has its own form: title, description, impact, urgency, category, plus a Solution field that holds the permanent fix once available. What it doesn't have out of the box is a separate "Known Error" status — you live with that gap by convention.
Two patterns work. First: a Problem in status Assigned or Planned with a clearly-formatted workaround in the description (e.g. a ## Workaround heading) is your Known Error. Second: add a custom field Known Error: yes/no via the Additional Fields plugin, which makes filtering and reporting cleaner. Either way, the rule is: as soon as a Problem has a diagnosed root cause and a workaround that L1 can apply, it counts as a Known Error.
Structure the workaround so it's actionable in 60 seconds
A Known Error record that just says "VPN occasionally drops on Win11" is almost useless. The reader needs to know: how do I confirm I'm seeing this Known Error, and what do I do? Use this structure in the description:
- Symptom — how the user reports it. Exact wording you've heard ("VPN disconnects after 5 minutes", "Outlook stops sending"). L1 matches incoming tickets against this.
- Detection — how to confirm. Specific check: "Run
ipconfig /all, verify the VPN adapter has IP 10.50.x.x". This separates this Known Error from look-alikes. - Workaround — exact steps. Bulleted, copy-paste-able. "1. Open Settings > Network. 2. Right-click VPN profile. 3. Properties > Security > uncheck Use IPv6."
- Permanent fix — status. "Vendor patch expected in 25.4 release, ETA Q3. Tracked in ticket #2847."
- Workaround scope — who can run it. "L1 can apply. Requires no admin rights."
Five sections, two paragraphs each, and you have a record that turns a recurring 30-minute investigation into a sub-five-minute resolution by anyone on shift.
Link incidents to the Known Error from the ticket form
When an incident matches a Known Error, the agent should not just resolve it from memory. From the ticket detail page, scroll to the Linked tickets / Problems section and link to the Known Error. Two things happen: the incident's solution can reference the Problem ("Resolved via Known Error #142 workaround"), and the Problem's incident count goes up — quantitative evidence that the workaround is still needed and that the permanent fix is worth budget attention.
The incident count on Known Errors is also how you prioritize the permanent-fix backlog. A Known Error linked to 80 incidents over six months has a different business case than one linked to two. Without the linking, you fix what shouts loudest. With it, you fix what costs the most.
Surface the database where L1 actually looks
A KEDB in Problems > All Open is invisible. Add a saved search "Open Known Errors" pinned to L1's profile dashboard. Add a Knowledge Base article that's just a contents page linking to the most-applied Known Errors. Train: any time you investigate something and recognize "this matches Known Error X," link the incident, then return there if you forgot anything.
Close the loop quarterly. Review Known Errors with zero new incidents in 90 days — the workaround may have been built into a deployment, or the issue genuinely went away. Close them or mark "resolved by ambient change." Review Known Errors with rising incident counts — those need escalation to the permanent-fix queue. A KEDB that grows without pruning becomes the same noise as the queue it was supposed to relieve.