How do you create a Known Errors in a Known Error Database in ServiceNow?

CHarrison
Kilo Contributor

The company I work for is looking to improve how Known Errors are created and tracked out of Problems (version is Jakarta) and I am looking to for how to properly set this up. Right now they are using a Problem category called Known Error however once categorised as this it falls off everyone's radar and is not worked on and just sits as an open Problem with no activity. 

What is the best way to set up a Known Error Database in ServiceNow and be able to track the KE while still working on the Problem?

 

Note: I checked previous threads however they are out of date by years.

1 ACCEPTED SOLUTION

David Ramirez
Kilo Guru

As shown on the release notes for problem management in Jakarta, and with the purpose of aligning with industry best practices, Starting in Jakarta the baseline field (true/false) named Known Error is hidden from the default form view, and it is instead automatically set to true when the state of the problem is set to known error. Before Jakarta using this checkbox was a way to mark the problem while still working on it, but I would not recommend going back to doing this, as it goes against the idea that known error means the root cause is identified but can't/won't be fixed, e.g. internet explorer is not supported by "ABC" and that can't be changed.

You can make sure that the problem stays in the radar in a few ways, one would be to automatically trigger the creation of a knowledge article in a knowledge base / category that will be used by technicians/agents using incident deflection contextual search.

The other suggestion I have is that if there is still work to be done in a problem and therefore you don't want to set the state to known error, then using the "communicate workaround" feature may be the way to go.

good luck,

David

View solution in original post

1 REPLY 1

David Ramirez
Kilo Guru

As shown on the release notes for problem management in Jakarta, and with the purpose of aligning with industry best practices, Starting in Jakarta the baseline field (true/false) named Known Error is hidden from the default form view, and it is instead automatically set to true when the state of the problem is set to known error. Before Jakarta using this checkbox was a way to mark the problem while still working on it, but I would not recommend going back to doing this, as it goes against the idea that known error means the root cause is identified but can't/won't be fixed, e.g. internet explorer is not supported by "ABC" and that can't be changed.

You can make sure that the problem stays in the radar in a few ways, one would be to automatically trigger the creation of a knowledge article in a knowledge base / category that will be used by technicians/agents using incident deflection contextual search.

The other suggestion I have is that if there is still work to be done in a problem and therefore you don't want to set the state to known error, then using the "communicate workaround" feature may be the way to go.

good luck,

David