Forum Discussion
Knowledge Base - setting up within O365/Sharepoint
We successfully built and deployed a KB in "Classic Sharepoint" in Office 365 last year. I hesitate to explain how we did this here, as it isn't possible in the new UI. We are waiting for the new Communication Sites to drop so we can see if we can re-build a Kb 2.0 using that as a substructure. I am not looking forward to the day when MS flips the switch to convert all classic sites to modern sites. I just know it is going to break all our hard work.
Wiki's seem old school now. OneNote has filled the role for teams to quickly and easily create their own knowledge base. Also with the online web access (OWA) for Word, PPT, etc., creating a standard library with files is the way to go - easier for users to create and manage content versus the complicated management of a wiki library. AND I haven't seen anything about wiki pages in the modern UI. I have created many wiki resource libraries to train users on SharePoint over the past 15 years but not anymore. That would be my last choice in the modern UI. Hope that helps.
Julie Sanders - The problem with what you proposed is the amount of admin overhead that take to keep that current or to ensure ppl have the correct permission set.
I dislike post-necro, but we followed a similar footprint as the one mentioned here, but had to get away from managed metadata as a sorting mechanism. The simple truth and reasoning behind it is our need for old school workflows that modify the title and tagging after the document is submitted. Yes we could incorporate the new "Flows" integration, but much of our SharePoint site was brought over from a legacy on-prem deployment that now has to coincide with what apps and controls MS allows us to have.
Instead of using MM, we use separate lists with choices, which allows us to customize the views using grouping and sorting.
The final product is a living document repository with a dynamic master document control list (instead of having to use a static excel spreadsheet). We have undergone a few ITIL audits where this type of file management has prevented several non-conformities, where human error and oversight would have occurred without the dynamic structure.
(Plus the best part is, with the dynamic headers on all documents pulling from the SharePoint document properties, they will always be printed (if necessary) with the accurate information.) There was heavy setup time on my part (about 70+ hours) but a similar solution through Bamboo will net you around 500$US residual.
Julie, I like your idea about using the standard library. I have tried using OneNote, and do love, and live in it. However, the OneNote KBs seems to get out of control real fast.
Back to you document library comment. Do you have any information you can share related to how you have setup and structured the library. Such as content type definition.
Thanks for you comments.
Potentially lots of information architecture work to get organized to get the tags right but you'd have to do this for a really organized wiki anyway. And yes, it is possible that you would need to use multiple content types but not a given. You just need enough tags to give the users the views they need to find what they are looking for. AND as the UI evolves you can easily jump into some of the modern UI web parts on a page if you that is helpful to users. Standard libraries and views just have the most flexibility in my opinion. And you let the content owners work in the format they are most comfortable in (e.g., Word).
