Known error database management concept ?

[Gaurav Kumar15]

Hi All,

We have the requirement to implement a new application "KEDB" in which the client is looking for the same functionality as of knowledge management, but they want that the number should start with "KE".

And on the other hand knowledge article will start with "KB". So will it be possible to implement the KEDB using existing knowledge table? Could someone please guide me on the same ? If not, then is there any way we can create new KEDB application on new table, but it should be searchable like knowledge articles.

TIA,

Gaurav Kumar

[Pradeep Sharma]

Hi Gaurav,

You may find below blog helpful.

A ServiceNow implementation of the Known Error Database

[Gaurav Kumar15]

Thanks Pradeep for the Quick response.

But i just had one more concern, like Knowledge works OOB.
Is there way we can create separate Known Error database on custom table and which should be searchable like knowledge articles.

As we are looking "Knowledge" and "KEDB" as 2 different applications and client wants that numbering should start with "KB" for knowledge and "KE" for KEDB.
So for achieving this, i think using "kb_knowledge" table is not enough. So we need to create new table and have to start numbering with "KE" and rest everything should be similar to knowledge.

Thanks & regards,
Gaurav Kumar

[johnbarber_now_]

Hi Gaurav, I would think you could extend the knowledge table to get your KE numbering in place or duplicate the table, look at #7 in the following wiki:

Creating a Custom Table - ServiceNow Wiki

From a process stand point you might consider just using PRB as your Known Error DB, and having a KB directly built out of PRB once it reaches a state of "Known Error". Basically, in a larger sense, a PRB is already tracking the risk of incident from a specific root cause; so technically if you have identified the root cause of your problems, but can't at the moment do anything to stop it from causing incidents, then the PRB is for all intents and purposes a "Known Error" and driver of Incidents. So your pool then of Known Errors to search through is simply your PRB with identified root causes, and you can sort this list by PRB priority, INT count, and a number of other ways to enable folks to find the PRB causing their INT quickly, and have easy access to the Knowledge built off that PRB.  

The KB off these PRB then become the "Known Error" instructions "What shall we do when this happens" and contain any workaround or actions folks can take to resolve the INT caused by the Known Error PRB quickly and what can be done to prevent a repeat INT from the PRB. One then can differentiate the Normal KB from the "Known Error" KB by simply filtering KB which are built off a PRB. Which might be easier/simpler then trying to extend or create a new custom table.

Lastly, There are some PRB that the ROI is just not there to resolve the PRB, and one decides that at least for now they will accept the risk of the PRB knowing more incident will be caused by that PRB, Often it is good to have a "Accepted Risk" state in your PRB state model so you can differentiate the PRB actively being worked towards resolution and the ones, which represent acceptable risk of incident. Any PRB moving to this state should likely be forced to have a KB article published off the PRB, so that when the INTs occur the support teams quickly have the information they need to resolve the INT as quickly as possible.

Long story short, you can use the OOB Knowledge and still get the separation of which KB are known errors, by applying some simple tooling changes to PRB.

Anyway I hope the information and other perspective on "Known Error" is helpful, JB