We are developing a knowledge base at Corporate. We have several remote sites (different site collections) and wish to give designated Subject Matter Experts (SME's) the ability to share information company wide via the knowledge base.

Several ideas are being suggested as to how to achieve this. One is to enable Cross Site publishing to provide SME's with the ability Catalog enable document libraries. This library would be picked up by the search engine and we could surface the content via a Content Search Webpart.

The other is to add a document center to the Knowledge Base and have remote users simply drop their content in that Library.

We use SharePoint 2013

Anyone have a similar use case? Thanks

1 Answer 1


I think the Catalog is a great idea for a KB. It is an elegant way to publish large amounts of front-facing content to an arbitrary location. In my case, I used a catalog to build a menu of assets managed by the IT department.

This page gives a great tutorial on how to set up a Catalog from scratch: https://docs.microsoft.com/en-us/sharepoint/administration/an-introduction-to-cross-site-publishing

The advantage of the Catalog is that you can silo all your KB content in one site collection and publish it anywhere else, even if the consuming site's users have no access to the KB site.

The disadvantage of the catalog is that you need to put extra effort into developing the presentation and navigation, which includes making new Display Templates and possibly modifying your Search Schema accordingly. This is not too onerous, but it involves many steps and multiple days of work. As well, obviously, when you customize things like this you increase the amount of overhead necessary to make changes to the system in the future.

When you create a new catalog, you can (optionally) also create new Page Layouts specifically for that Catalog's items. These layouts include a Content Search Web Part (already configured to retrieve items from the Catalog) by default, but nothing else. I would recommend to use (and customize) these page layouts rather than using existing ones, just so you can avoid inadvertently changing other pages.

Depending on how you want your end-users to navigate through the content, you may want to set up a Managed Navigation node in the Term store, so that you can assign friendly URL's (i.e. Terms) to the individual items in your catalog. This sounds like a good idea in theory, but in practice I've found it difficult to control the exact behavior of the Managed Navigation hierarchy in the Quick Launch. The default Quick Launch is clunky and hard to change without also modifying Page layouts or Master pages, so I avoid using it.

In my case I added a Managed Metadata Refinement web part to my Catalog category Page Layout, so that users can narrow down the visible catalog items by selecting tags, but this is inelegant.

If you want maximal control (for example, to make a nav like on this page) you may need to build a custom solution in the Page Layout.

Another caveat to using the Refinement web part is that it requires the properties on your catalog items to be set as Refinable in the Search Schema. Managed properties can only be set as Refinable at the Search Service Application level; otherwise you need to map your items' properties to the empty RefinableXXX managed properties in the Site Collection Search Schema. For more info on that, see here: https://docs.microsoft.com/en-us/sharepoint/search/how-to-add-refiners-to-your-search-results-page

If you are using a Content Search Web Part to surface Catalog items, then you will need to select a Display Template to show the items. The default ones are not great- they look old and have limited slots for returning item properties. I would suggest creating a custom Display Template so you have greater control over the style and presentation of each item. Here is an article on that topic: https://blogs.technet.microsoft.com/sharepoint_quick_reads/2013/08/01/sharepoint-2013-customize-display-template-for-content-by-search-web-part-cswp-part-1/

So, ultimately, using a catalog involves the following

  1. Enable the Cross-Site Publishing feature
  2. Configure a list/library as a catalog
  3. Catalog Result Source (created automatically when you create the catalog)
  4. Catalog Category & Item Page Layouts (optionally created when you create the catalog)
  5. Managed Navigation Term Set
  6. Managed Properties in the Site or Search Service Schema
  7. Display Templates for the Catalog Page Layouts

The workflow would then be like so:

  1. SME's go to the KB site and author content (as a SharePoint page, Office doc, etc.) in the KB Catalog
  2. SME's add metadata to their articles that will be surfaced by the Content Search Web part on the Catalog Pages (such as category, hashtags, description, etc.)
  3. The Search Service eventually crawls the catalog and picks up the new content
  4. Users can then see and engage with content from the Catalog page
  • This is fantastic information Chris. Thanks very much! Commented Oct 9, 2018 at 16:38
  • Hey Chris, quick point of clarification....The Yale link you included in your post. It's really a nice site! But that isn't SharePoint is it? I viewed the source and it doesn't seem like it? Thanks! Commented Oct 11, 2018 at 19:31
  • Hi Martin, no I don't think it is SharePoint but some kind of JS framework instead. It does look like SP though. That was the site I used for inspiration when building my IT Assets catalog- I think the presentation is very good, from an end-user perspective. Commented Oct 12, 2018 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.