- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-22-2021 09:21 AM
I'm exploring changing our current knowledge categories because the categories are so vague that they end up not being useful and we have the same categories across knowledge bases, so the user interface looks messy.
I've found information in various places that supports that we should not have the same categories across knowledge bases (For example: https://community.servicenow.com/community?id=community_question&sys_id=9edecf61dbdcdbc01dcaf3231f96...
I'm wondering if anyone has information/best practices around how to use categories. From what I see, it improves the user experience by giving filtering options and you can use them for metrics. Can you design approval workflow using categories? Are there other benefits? One of the questions that I'm getting is, why use categories when people should be able to find what they need using search.
Solved! Go to Solution.
- Labels:
-
Knowledge Management

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-22-2021 12:46 PM
I think it depends on the size of your knowledge base. Each knowledge base is already the first form of categorization. So if a KB is small and has good keywords then search may be enough. But if you have several thousand articles per KB people appreciate the ability to narrow their search. An article is worthless if it's not findable.
Come up with some minimal guidelines about how many categories and subcategories you want per knowledge base and the min/max # of articles per level. Then get input from the departments that use the knowledge bases to determine the major groupings, the category labels and definitions. The self-service user will have a different view of search terms than the technical searcher.
We redid our category structure last year. One knowledge base didn't have one, and the other was minimal and barely used. We do not repeat categories across KBs. Category is not a mandatory field, but we make sure it is filled out in every article. Our category structure settings are locked down to the knowledge admin to control the min/max structure, formatting, etc. When bringing a new group into authoring we discuss the categories they will use and create new ones if necessary. Because our knowledge bases were scrubbed extensively since category implementation, we will soon review the structure for levels that no longer meet our min/max limits, combine articles into higher levels and inactivate unneeded levels.
We started with 8-10 categories per level (suggested through internet research) and no more than 2 subcategories per category, with a minimum of 25 articles per level. Less than that and they go to the higher level. Repeat the level name in the labels so they line up well for reporting. Mind your field character limits when you plan labels.
Category
Business
Subcategory 1
Business Conferencing
Business Office 365
Subcategory 2
Business Office 365 Excel
Business Office 365 Outlook
Business Office 365 Word
I'm not sure how category would be useful in the approval flow, unless it was a field one looked at to determine if they were the best qualified approver to review a particular record. It might be useful in Incident/Knowledge used reports.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-22-2021 12:46 PM
I think it depends on the size of your knowledge base. Each knowledge base is already the first form of categorization. So if a KB is small and has good keywords then search may be enough. But if you have several thousand articles per KB people appreciate the ability to narrow their search. An article is worthless if it's not findable.
Come up with some minimal guidelines about how many categories and subcategories you want per knowledge base and the min/max # of articles per level. Then get input from the departments that use the knowledge bases to determine the major groupings, the category labels and definitions. The self-service user will have a different view of search terms than the technical searcher.
We redid our category structure last year. One knowledge base didn't have one, and the other was minimal and barely used. We do not repeat categories across KBs. Category is not a mandatory field, but we make sure it is filled out in every article. Our category structure settings are locked down to the knowledge admin to control the min/max structure, formatting, etc. When bringing a new group into authoring we discuss the categories they will use and create new ones if necessary. Because our knowledge bases were scrubbed extensively since category implementation, we will soon review the structure for levels that no longer meet our min/max limits, combine articles into higher levels and inactivate unneeded levels.
We started with 8-10 categories per level (suggested through internet research) and no more than 2 subcategories per category, with a minimum of 25 articles per level. Less than that and they go to the higher level. Repeat the level name in the labels so they line up well for reporting. Mind your field character limits when you plan labels.
Category
Business
Subcategory 1
Business Conferencing
Business Office 365
Subcategory 2
Business Office 365 Excel
Business Office 365 Outlook
Business Office 365 Word
I'm not sure how category would be useful in the approval flow, unless it was a field one looked at to determine if they were the best qualified approver to review a particular record. It might be useful in Incident/Knowledge used reports.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-25-2021 05:34 AM
Thanks, this information is really helpful.