How to mark the Problem record as Known error

[BVD]

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)."

[Matthew_13]

Hopefully this helped you my friend.

[Matthew_13]

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

[BVD]

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).

[Matthew_13 · Accepted solution]

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.

[CJB123]

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.