question Re: How to mark the Problem record as Known error in Virtual Agent forum

How to mark the Problem record as Known error

BVD — Mon, 15 Dec 2025 14:36:59 GMT

Hi,

Once the root cause is determined, before the fix implementation is there a way to mark/show the Problem record as Knownerror.

I am looking a flow like root cause analysis -> Known Error -> Fix in Progress.

"A Known Error is a Problem that has been analyzed but not resolved, with its root cause identified

and a workaround documented in the Known Error Database (KEDB)."

Re: How to mark the Problem record as Known error

Matthew_13 — Mon, 15 Dec 2025 14:58:52 GMT

Out-of-the-Box (OOTB) ServiceNow Behavior

1. Known Error is a status/flag on the Problem record

In OOTB ServiceNow:

A Known Error is not a separate record type
It is a Problem record with the “Known Error” flag set
The record is typically in the Root Cause Analysis or Known Error state

Key fields:

State = Root Cause Analysis / Known Error
Known error = true

Re: How to mark the Problem record as Known error

Matthew_13 — Mon, 15 Dec 2025 15:00:20 GMT

Once root cause is identified:

Open the Problem record
Populate:
- Root cause
- Workaround
Set:
- Known error = true
- State = Known Error (or equivalent RCA state depending on config)

But this all depends on if your setup is OOTB or custom.

Re: How to mark the Problem record as Known error

Matthew_13 — Mon, 15 Dec 2025 15:01:51 GMT

Good video as well: https://www.youtube.com/watch?v=5E5zfTMICY0

Re: How to mark the Problem record as Known error

BVD — Mon, 15 Dec 2025 15:02:51 GMT

Thank you for the reply.

How can mark the

Known error = true

I remember a check box during Jakarta time.

Re: How to mark the Problem record as Known error

Matthew_13 — Mon, 15 Dec 2025 15:55:08 GMT

Indeed; here is Jakarta vs now:

In Jakarta, there was a visible “Known error” checkbox.
In newer releases, Known Error is usually handled by the Problem State, not the checkbox.

How to mark it now (I recommend this)

Open the Problem record
Set State = Known Error
Fill Root Cause and Workaround

If you want the checkbox back

Right-click form → Configure → Form Layout
Add Known error (known_error) if it exists

A great Best practice: Use “State = Known Error” instead of the checkbox.

Re: How to mark the Problem record as Known error

Matthew_13 — Mon, 15 Dec 2025 21:57:52 GMT

Hopefully this helped you my friend.

Re: How to mark the Problem record as Known error

BVD — Mon, 22 Dec 2025 14:29:33 GMT

Hi Matthew,

The youtube video is referring to Known Error Article, which we are using. Apart from showing the Known error articke number on the Problem form, it does nothing to the Problem record state.

Response to your suggested solutions,

1.) And out of the box there is no state called "Known error", dont want to customize

2.) I do see a check box for Known error but selecting this check box again does nothing to the Problem record or its state. I can select this check box at any state which should not be the case.

I would like to understand what is ServiceNow recommended way of managing Known errors (not known error articles).

Re: How to mark the Problem record as Known error

Matthew_13 — Mon, 22 Dec 2025 15:43:41 GMT

Thanks for the feedback;

ServiceNow does not treat Known Error as a Problem state. It’s a classification, not a lifecycle step.

That’s why:

There is no “Known Error” state out of the box
Selecting the Known error checkbox does not change the Problem state
The checkbox can be selected in any state (by design)

ServiceNow’s recommended OOTB approach is:

Use Problem states to track lifecycle (RCA, Fix in Progress, etc.)
Use the Known error checkbox to indicate the root cause/workaround is known
Link a Known Error Article to document the workaround

The YouTube video focuses on Known Error Articles because that’s where the real OOTB functionality is. Enforcing state changes or adding a “Known Error” state would require customization.

Re: How to mark the Problem record as Known error

CJB123 — Wed, 14 Jan 2026 12:28:46 GMT

As someone who has worked in and around the Problem Management function for 10 years, I am not a fan of the current OOTB methodology and design for Problem.

While the essence that known errors are not a 'state' of the workflow and merely an indicator via checkbox should enable a ticket to be highlighted that it is a known error in any stage of the 'workflow'. I feel this is flawed by design in terms of how these tickets are also managed.

Many companies and Problem Managers will report on active tickets and known error or even root cause unobtainable tickets as separate commodities, as many known errors will have, for example, workarounds added and require time, resource capabilities or other factors to be available before permanent solutions can be presented. As such, known errors are often out into a 'state' of known error, as this enabled these to be reflected in a pending state (same as with root cause unobtainable). This means that incidents can still be linked to these problems, as they remain open (if they are closed this capability is removed), but the tickets themselves no longer reflect in the active working queues, as they are seen as pending other outcomes before they can be moved back to active and progressed further.

Enabling Problem Management to manage these separately and under different status, reporting and often providing an in built method for a KEDB.

The current method removes much of this capability and simply reflects all tickets in a flow state which is not always valid and correct.

I would add, that the workflow does not account for known errors where the root cause is known, but the state 'fix in progress' is not valid, as there is no viable fix at the time, possibly due to many factors, including capability, resource, funding or infrastructure.

I hope this is reconsider and redesigned in the near future to be more inclusive of both known error and root cause unobtainable responsibilities of problem management.