ServiceNow Known Error Explained

What a Known Error Is

A known error is a problem that has been investigated and documented with a permanent or temporary workaround. Rather than solving the underlying cause immediately, teams document the problem so that when similar incidents occur, responders can apply the known workaround without having to investigate from the beginning. Known errors accelerate incident resolution by providing short-term relief while a long-term fix is planned.

Known errors differ from regular problems in that they have documented, tested workarounds. A known error record includes a description of the symptoms, the conditions under which the problem occurs, the workaround that provides relief, and ideally the progress toward a permanent fix. When an incident occurs that matches the known error symptoms, the responder can apply the workaround instead of spending time investigating.

Where Known Errors Live in ServiceNow

In most implementations a known error is a problem record with the Known error flag set, so it lives in the problem table; check how your release and any custom tables handle it. Each known error record includes a title, description, symptoms, cause, and one or more workarounds. The record also captures the state of the known error: is it still active, or has it been resolved and archived? Related incident records link to the known error that applies to them, creating a relationship that helps teams reuse solutions for recurring problems.

The Problem Management module provides the interface for creating and maintaining known errors. When a problem is investigated and a workaround is documented, that information becomes a known error record. The record can remain active as long as the problem persists, and can be closed once the underlying issue is permanently resolved.

Incident responders consult the known error database when handling incidents. If an incident matches a known error, the responder can apply the workaround and provide immediate relief to the customer. The known error database is often searchable based on symptoms or technical keywords, helping responders find applicable known errors quickly.

A Worked Example: Database Connection Problem

Suppose a database application occasionally fails to reconnect after network interruptions. The problem investigation reveals that the application does not properly handle connection timeouts and requires manual intervention to restore the connection. A permanent fix requires code changes and testing, which might take several weeks.

Meanwhile, the temporary workaround is to restart the application service, which forces a new connection and restores functionality immediately. This information is documented in a known error record titled Database Application Connection Timeout. The workaround says: stop the application service, wait two minutes, then start it again. When incidents occur with similar symptoms, responders apply this workaround immediately instead of investigating.

The permanent fix proceeds in parallel. Once the fix is deployed and verified, the known error record is closed and archived. The workaround is no longer needed, but the historical record remains for reference.

Common Misunderstandings About Known Errors

One misunderstanding is thinking that known errors are a failure of IT operations. In reality, known errors are a normal part of IT service delivery. Systems are complex, problems sometimes take time to solve permanently, and documented workarounds reduce impact on users while permanent solutions are being developed. Effective known error management is a sign of mature problem management, not inadequacy.

Another confusion is assuming that all workarounds should remain in place indefinitely. Good practice is to track the progress toward permanent fixes and close known errors once those fixes are deployed. Known errors that remain open for long periods should be reviewed to ensure that permanent fixes are actually being progressed.

Some teams confuse known errors with knowledge articles. Knowledge articles are general guidance that may apply to many situations. Known errors are specific problems with specific workarounds. A knowledge article might provide general troubleshooting steps, while a known error provides the exact workaround for a specific recurring problem.

Managing Known Errors and Related Workarounds

Known error management includes tracking which incidents are associated with each known error, monitoring how often workarounds are applied, and measuring the time saved by having documented workarounds. This data supports decisions about which problems to prioritise for permanent fixes.

Known errors can be linked to configuration items, so when a particular application or system is having problems, you can query to see what known errors affect that component. This relationship helps teams understand the health and stability of their infrastructure and identify which components need attention.

Closing known errors requires verification that the permanent fix has been deployed and is working. The relationship between known errors, problems, and incidents creates an audit trail showing when issues occurred, how they were resolved, and when permanent fixes were implemented.

When a workaround earns the right to be published

A workaround is only useful if the person applying it at an awkward hour can carry it out without asking anyone. That is the test a known error has to pass before it goes live. The problem manager who wrote the record usually knows the cause well, but the responder who opens it during a queue spike knows only the symptom on their screen. The record has to bridge those two positions, and weak known errors often fail because they were written for the first reader alone.

Ask whether the workaround can be executed by someone who did not investigate the problem, whether it can be undone if it makes things worse, and whether it is reversible without a change record. If the answer to the last question is no, the known error is a change proposal in disguise and belongs in the change process, not in a responder’s reference list.

Workaround type	Safe to publish directly when	Route for approval first when
Restart or clear a component	The restart is routine, has no data impact and is already in the operations runbook	The component serves a regulated process or customer-facing transactions in flight
Redirect traffic or switch to a secondary path	The secondary path is tested and capacity has been confirmed by its owner	The redirect changes which data is stored or where it is processed
Manual data correction on a record	The correction is limited to fields the responder is already permitted to edit	The correction touches financial, personal or access data
Disable a feature until the fix ships	The disabled feature has a documented business fallback agreed by its owner	Disabling the feature removes a control or a notification someone relies on

Publishing a known error in an order that holds up

Teams often publish the record as soon as the first workaround is found. A safer order keeps the record honest about what is known and what is still being tested. Each step below should leave a trace on the record so a later reviewer can see how the decision was reached.

1. Confirm the problem record already links the incidents that show the symptom, and that the symptom description matches what responders actually see.
2. Write the cause as far as it is understood, and mark any part that is still a hypothesis.
3. Run the workaround on a non-production copy and record the exact conditions under which it was tested.
4. Name the group that will apply the workaround and confirm it has the access to do so.
5. Agree how the workaround is undone if it fails, and write that step into the record beside the workaround.
6. Publish with a state that shows the fix is still open, and set the next review date before the record leaves draft.

Failures that show up after the record is live

• The workaround stops working after an unrelated change, but the record still says it does, so responders waste time on it.
• The symptom description is so broad that unrelated incidents get linked, and the workaround is applied to the wrong service.
• The record is closed when a temporary fix is deployed, though the underlying cause was only partly addressed.
• Responders apply the workaround without raising an incident update, so the metrics show the problem as resolved in a way nobody can reproduce.
• A known error sits open for so long that the business stops expecting a permanent fix, and the workaround becomes the service.

The last failure is a governance problem more than a technical one. Ask the owner of the affected service to confirm, at a set interval, that the permanent fix is still funded and scheduled. A known error with no funded fix is a standing risk, and it should be reported as one.

Measures that show the record is earning its place

Count how many incidents are linked to each known error, how many of those were resolved by applying the stated workaround, and how many were reopened within a short period afterwards. A workaround that is applied often but reopens incidents is a warning sign, not a success. Track time from first report to workaround applied, grouped by assignment group, because a long gap can reveal that the record is hard to find rather than hard to understand.

Set the acceptable ranges from your own history. A single target across all services hides the difference between a checkout outage and a slow report, and that difference is what your service owners need to see.

Cases where a known error is the wrong instrument

A known error should not hide a control gap. If the workaround depends on disabling authentication, skipping an approval or granting a broad role for the duration, the issue is a security or governance decision, and it needs the owner of that control to sign off. Similarly, when the symptoms vary so much that no single workaround fits, a known error creates false confidence. In that case the better step is more investigation, with a problem record that tracks the hypotheses being tested.

The other case is the single incident. If a problem has happened once and is not expected to recur, a full known error adds paperwork without a benefit. A clear note on the incident and a closed problem record are usually enough.

Questions responders and owners ask about known errors

Who signs off on a workaround before it is published?

The problem owner writes it and a second person tests it. Where the workaround touches a service with its own change authority, that owner signs off too. Record the approval on the workaround record, because an approval kept in an inbox cannot be found when the next responder asks who signed it off.

How do we stop responders using a workaround that no longer applies?

Give the record an expiry or review date tied to the change that is expected to remove the cause, and check the record whenever that change is scheduled or deployed. Removing a workaround is a change in its own right, so it should go through the same path as adding one.

Does every known error need its own problem record?

In many setups the known error is the problem record in a known state, not a separate object. What matters is that the cause, the workaround and the permanent fix are all visible from one place, and that closing the record requires evidence the fix worked.

What happens when two known errors describe the same symptom?

Merge them if the causes match, or split the symptom description so each record covers a distinct trigger. Two records with overlapping symptoms send responders in circles, and the first one they find decides the outcome, which is often not the one with the better workaround.

Next step for a known error practice that is not yet working

If workarounds are living in chat threads and personal notes, start by listing the ten most-linked incidents of the last quarter and checking whether each has a usable record. The gaps will show where the practice should begin. The problem record page explains what a problem record is and how it links to the investigation, and the known error guide covers what makes the record useful. For recurring cases, the recurrence guide covers turning repeated incidents into action that can prevent the same failure.

Known error, known issue and problem: how to tell them apart

In problem management, a known error is a problem whose cause is understood or whose workaround has been tested, written down so responders can reuse it until a permanent fix is deployed and checked. A known issue is the looser phrase: a fault someone has acknowledged, often a supplier in release notes, with no promise that a workaround exists.

The four terms people mix up behave differently once tickets are open.

Term	What it describes	Stays open until
Incident	One disruption to one user or service	Service is restored for that case
Problem	The underlying cause behind one or more incidents	The cause is fixed or the risk is formally accepted
Known error	A problem with a documented cause or a tested workaround	The permanent fix is deployed and verified
Known issue	An informal acknowledgement of a fault, often with no workaround	Nobody tracks this; it simply stops being mentioned

The practical consequence shows up at the service desk. When someone asks about a known issue, test it against the known error definition before publishing anything. A known issue with no tested workaround should not sit in a responder’s list as if it had one, because the responder will apply a step nobody has proven. Keep it on the problem record as an open investigation, and promote it to a known error only when someone has run the workaround and written down what happened.

When people search for a known error record, they usually mean the same thing described above: a title, the symptoms a responder will see, the conditions that trigger it, the workaround, and a link to the problem that carries the permanent fix. Write the symptoms in the words a user would use, not the words of the team that diagnosed it, since that is what a responder will type into the search box.

Some teams also record a known error when the cause is known but no workaround exists. If yours does, say so in plain words at the top of the record so responders escalate instead of hunting for a step that is not there. The problem management guide and the problem record explanation show how the two records relate, and the knowledge management guide covers where published workarounds should be kept.

Known error fields, tables and state names to check on your instance

In most ServiceNow implementations a known error is not a separate object. It is a problem record with the Known error box ticked, a documented cause and a tested workaround written on it. Responders reach it through the problem link on their incident, so the fields below decide whether the workaround can be found.

These are common out-of-box names. Labels and defaults change between releases and many teams extend them, so check each one on your own instance and release before you build reports or rules around it.

Where	Name	What it does
Table	problem	Holds the investigation, and the known error when the box is ticked
Problem field	known_error	True or false flag that marks the record as a known error
Problem field	workaround	The step a responder applies while the permanent fix is open
Problem fields	cause_notes and fix_notes	Where the cause and the planned fix are written
Incident field	problem_id	The link from an incident to the problem that explains it

The state field on a problem commonly offers values such as New, Assess, Root Cause Analysis, Fix in Progress, Resolved and Closed. Teams commonly flag a problem as a known error once a workaround is documented while the permanent fix is still open, so state and flag should show where things stand.

Example (hypothetical): a service desk keeps getting reports that a scheduled export never arrives. The problem record shows the cause as a stalled job queue. The workaround field says to clear the queue and restart the job, and the Known error box is ticked. A responder links the next incident through problem_id and reads the workaround without opening the investigation notes.

The problem management practices guide explains how the investigation side works, and the incident management guide shows how responders find the link. For where long workaround text should live, the knowledge management guide covers publishing and review.

How does a responder find a known error from an incident?

Through the problem link on the incident. Opening the linked problem shows its Known error flag and its workaround, so the responder can apply the documented step without repeating the investigation.

Does the workaround belong on the record or in a knowledge article?

Keep a short, tested step on the record, because that is the text the incident points to. Move longer procedures into a knowledge article and reference it from the workaround, so one place carries the detail and the record stays readable.

What should the state of a known error show?

That the permanent fix is still open. A known error in the fix stage tells responders the workaround is temporary. Many teams keep the problem out of Resolved and Closed until the permanent fix is deployed and checked, so the workaround stays easy to find while it is still needed.