Best practice when it comes to knowledge bases in SN

[Cristina Silva]

Hi again,

Now I'm seeking best practice tips regarding knowledge bases in SN, which are the limitations and possibilities in having one versus several knowledge databases. We have today a setup with 3 knowledge bases - one for news, one for WoW (routines, instructions) and one for QA. We are looking into maybe just have on KB but are there any disadvantages towards going to one KB? What does SN say about having several KB, are the possibilites larger when it comes to user criteria (can read, cannot read etc)? Is best practice to have one KB per department, for example IT, HR etc? 

Thanks in advance,

Kind regards Cristina

[Vickie Runyon]

There are pros and cons to each approach—some considerations around what you are trying to achieve and whether your audiences will overlap or not.

For us, we have 4 KB today but are consolidating down to one. We are providing knowledge related to tech support and our audience is all team members ("public" but inside the company only). Three of our current KB are limited visibility to our support teams (client support, tech support, and after-hours support vendor) and the fourth KB is open to all team members.

We have decided to switch to a single KB (public) with a custom template with field-level ACLs to limit visibility. The restricted fields will have tech support details and are not visible to the public audience.

The biggest advantage of this approach is having a single article for a single issue. With 4 KB, we might have had 4 different articles which meant maintenance costs were high to maintain the same information in multiple locations.

The downside to switching to this approach is having to recreate the existing articles in the new template and then retiring the existing articles. This means that any previous KB numbers are also retired so any saved links will no longer work.

If instead, we had differing audiences such as HR-related topics or client-facing articles, then separate KB might make sense. SN makes it very easy to grant or deny access to KB with User Criteria. There's also the option of scoped KB that can be further locked down so that even an SN Admin cannot see the content unless they are explicitly allowed - a great feature for sensitive content that might be seen in an HR KB scenario.

In either scenario, KB articles are only visible to those that have access to them - no matter the access method (in the platform or on a portal, or via a direct link).

Probably the most important thing is to make your design decisions before you create KB articles at all - then you won't be in our situation and recreating articles later down the road.

[johncruz0081]

The best practice for knowledge bases in SN is to create a comprehensive and up-to-date resource that is easily accessible to users. This should include a search feature to help users quickly find the information they need. It should also include detailed tutorials, FAQs, and other helpful documents to provide users with the information they need. Additionally, it should include a feedback system to allow users to submit questions or comments, and a way to track and monitor user feedback. Finally, it should also include a way to notify users when new information is added or updated. And according to RoyalOnlineClasses Best practice when it comes to knowledge bases in SN is to ensure that the content is up to date, accurate, and relevant. It is also important to make sure that the content is easy to find and navigate. Additionally, it is important to create a content structure that will help users find the information they need quickly and easily. Finally, it is important to have a system in place that allows users to ask questions and get answers in a timely manner.