Known Errors: Behind the Scenes

[Erich Zirnhelt]

After all of the Known Error changes we've made over past couple of months, you might be wondering - what happens when I report or discuss a product issue? Does anyone actually review or follow-up with it?

When a Product Issue is created, the team at ServiceNow is notified that a new issue has been posted. We allow some time to let other community member step in with their own insights and feedback. After a some time has passed, we take action. We consider several factors to determine if our action is required, such as activity and popularity of the post, or the impact of the issue. If the issue needs to be more clearly defined, or we need to confirm the steps to reproduce, we may prompt the original poster with some questions.

The product issue, PRB, Known Error assembly line:

1) Identify if the Known Error or PRB exists. The first step in working with the information provided is to compare the details against our existing set of Known Errors and Problems in HI.   Although we publish many of these, there are still several in the early, pre-publication stages.

2) Create a relationship between the product issue and the Known Error in HI. If we find a matching Known Error, we will update the Product Issue with the ID of the Known Error KB article. This creates a relationship in HI between the Problem record and the Product Issue from the community, giving the developers an easy view of the conversation.

3) Get the content created. If a PRB or Known Error does not exist, the teams at ServiceNow work together to get the content created.

• If there's no Known Error created, but a Problem exists, we'll ask the assigned developer to create and submit the article.   Our KB content team will then copy edit and publish it.

Here, James reported an issue with missing table and field names. bianca.vaccarini found the matching Problem and accelerated the publishing of the Known Error article.

• If no Problem exists, and we've confirmed the issue, we'll have one of our Support Engineers create the Problem and route it appropriately.

In this thread, Mallikarjuna Potha reported a Product Issue with the Data Lookup Definitions. A workaround was shared by Gigi Sossi and a Problem was created. Ben Phillips recorded the Workaround in the Problem, Tyler Jones created the KB article, and Suzanne Smith reviewed and published it.

There are some cases where a reported Product Issue is actually an expected product behavior or isn't necessarily an issue with the product. Our community is very good at helping each other out of potentially confusing situations and clarifying any intended behavior if it is not recorded in the product documentation.   When this happens, we will switch the Product Issue into a Question so that the Original Poster can credit the helpers with Correct or Helpful Answers.

4) Update existing documentation to fill in gaps. If the conversation leads us to determine that the documentation needs to be updated, we'll work with the Product Documentation team to make the required changes, as bianca.vaccarini did here.

All this adds up to a flexible and responsive approach to capturing and cataloging your issues, from hiccups to hurdles. The community gives us an outlet to hear your feedback and identify gaps in our self service documentation.   What do you think about the use of Product Issues on the community? Do you have any suggestion on what we could do to improve the experience? We would love to hear from you in the comments.