Do we need a separate Known Error knowledge base?

[Janelle3]

Hi,

Known Error means several things in our environment:

• We have a Known Error Knowledge Base – the repository where the article is stored, articles in a particular Knowledge Base follow the workflow and visibility/access settings for that Knowledge Base.

• We have a Known Error article template type – determines the fields of the article, for example ours contains special fields Workaround and Cause.

• Problem records have their own references to Known Error. A Problem record has a Known Error flag, a reference field to a Primary Known Error article and the Problem State can be Known Error.

We currently have a lot of confusion around what a Known Error means. There are no restrictions on what article types can be stored where, so we have articles following the known error template outside of the Known Error KB. Similarly, we have articles that follow the standard template within the Known Error KB. Then we have what Problem considers a known error, which is different again.

If someone asked me how many known errors we have, do I give them the number of articles in the Known Error KB? or the number of articles using the template? Or the known errors linked from Problem records? Confusion reigns!

Lately I've been questioning why we have a separate Known Error knowledge base at all. Some known errors are actually customer facing, while others are internal, yet because the Known Error knowledge base is a single repository we have had to set it as visible to everyone. If I removed the Known Error KB and instead focused on Known Errors as a type of article, I can store them in our internal or customer-facing knowledge base as appropriate.

What are you reasons for keeping / not keeping a separate Known Error Knowledge Base? 

Thanks,

Janelle

[Michele27]

Hi Janelle, I can relate to this and finally settled on:  reporting on articles which are linked to problem records. 

By simplifying the approach I don't need to worry about the knowledge base, the template used or the category selected.

🙂

[Janelle3]

Great solution! Thanks Michele. 

[David Kay]

I agree with you and Michele - ditch the  Known Error knowledge base and any kind of separate template for Known Error Articles.  Just use your favorite Solution / Problem Resolution / Break/Fix Article template.

The fact that a KB article exists at all lets the customer know it's a known *issue* -- it's hard to write an Article for an unknown issue!  Whether it corresponds to a defect you're tracking or not is of less interest to the customer: they want to know what the fix is (if there is one) and whatever workaround you can propose.  Sure, if it's a known issue and you're planning on delivering a fix, that's useful information, too, but not as important as getting the user through this problem.

As Michele says, I like to link to a defect / problem from the KB article, typically in an internal-only field.  Not only can you report on this, but every time someone gets these symptoms and pulls up the article, they can check to see if there has been any progress since the last time, and can update the article accordingly.  (Or use automation to help accomplish the same goal.)

[Janelle3]

Thanks David, those are excellent points. You're right, the customer certainly doesn't care whether we've classified it as a Known Error or not. I think getting rid of the separate knowledge base for Known Errors is the right call for our users. The last thing that gives me pause is that the KB exists OOTB and the Problem process defaults to creating known errors in this knowledge base. I'm always wary of changing things from OOTB.

I definitely agree that linking to the KB article from the Problem record is essential. 

Thank you again!

Janelle