The Enterprise Wiki in SharePoint has come a long way since it was introduced. At Puzzlepart, we now implement it in most client projects, particularly intranet sites. In this blog post I want to share some of our findings and show some of the practices we employ.

Among the killer features of Enterprise Wiki in SharePoint we find some that have been important for web publishers for over a decade, and which are now available to anyone: Collaborative editing, simple publishing using the Office Ribbon for rich formating, ability to use metadata, and support for display templates and webparts.

But don’t choose Enterprise Wiki due to features alone. Working on several client projects with different business requirements give us many great opportunities to experiment with how we plan and build Enterprise Wiki sites.

It is not always clear to customers how (or why) an Enterprise Wiki site should be used. Often, customers have some undefined idea in their head of what sort of site they need for their specific content, but they don’t quite understand how to communicate this in a way that helps us understand what they need.

When advising customers in projects involving Enterprise Wiki sites, there are four main areas to discuss:

  1. What sort of content will be published
  2. How will people use the content?
  3. How will this content be created?
  4. How will the content be maintained?


Screenshot showing an Enterprise Wiki containing governance documents, featuring custom navigation, taxonomy and related content.

What sort of content will be published?

The decision to use Enterprise Wiki should always be based on what sort of content the wiki will hold. Since the Enterprise Wiki site feature in SharePoint basically can be used for just about anything, here are some content examples:

Collaborative Self Help Guides

This is content which is written by colleagues, for colleagues, maintained by colleagues. It is a typical feature for many organizations. It contains content like “how to change your password”, “installing printer drivers” and “how to file an expense report”.

Organizational Information

This is more formal content, outlining the organizational structure and explaining what the various parts of the organization do. It can also hold content like history, employee bios, location information and other relevant items. We also sometimes use Enterprise Wiki to hold department pages, including employee listings.

HR information

This is more common content, usually in the form of Personnel handbooks. Content varies from standardized procedure descriptions to more specific content like vacation information, payroll routines and how to get a parking permit.

Governance sites

Typically manuals on how to comply with a system of rules. Examples are Quality Management Systems (QMS) sites, or sites built to support governance of areas like financal regulations (ie Eurosox) and similar legal requirements.


How will users actually use the content?

While an Enterprise Wiki is a great choice for publishing content, it also needs to fit real life usage scenarios in order to generate business value.

Here are some usage examples to illustrate the point:

Employees e-mail the content to external users

This is usually not a good idea for Enterprise Wikis on an intranet. Users may always choose to copy the content into an e-mail, or you can create a PDF export feature. Yet this is not a good scenario, and a standard document library holding files which can be attached to an email may be better.

Employees search and find answers to typical questions

This is an excellent candidate for an Enterprise Wiki. SharePoint Search is a great way to find content, and the search page will usually display search results with the page title and highlight relevant parts of the text, so that users can quickly scan a result set to find the best answer. It is also a good idea to employ SharePoint’s “Best bet” feature to place relevant search results on top of any search result page.

Employees write project notes and store them for later use

This is not a typical Enterprise Wiki scenario. Even though Wiki is a great place to store content, the Enterprise Wiki environment is not suitable for small groups. Either consider the Wiki page library which is a part of Team Sites, or – better – use OneNote, which is built right into SharePoint.

Employees use this content as authoritative guidelines

When a text is so important that employees will act according to the content, it needs to be reviewed and maintained over time. This is a good fit for Enterprise Wiki, as long as a governance plan is employed.

Before selecting Enterprise Wiki for content, always discuss usage scenarios for the actual content the site is going to hold.


How will the content be created?

Even if the content appears to be a prime candidate for an Enterprise Wiki, consideration should still be given to how the content is going to be produced.

Content which will be manually published, as in “we may as well publish it directly into SharePoint”, may be a prime candidate for an Enterprise Wiki. This opens up for leveraging the Enterprise Wiki’s excellent publishing features, which means that it is really easy to get quite large information areas up and running in relatively little time.

Note that team size is not necessarily a factor when considering Enterprise Wiki. Content which is produced by a single person, and maintained by the same person or a small team, can easily be targeted to the entire organization – which is an excellent argument for Enterprise Wiki.

If the content primarily will be created as a set of Microsoft Office documents, a standard document library in a Team Site may suffice. While we have worked on systems which automatically convert Microsoft Word documents to Enterprise Wiki pages (and vice versa), this can be too much work for some organizations, and there may be risks involved if the conversion fails.

Still, we sometimes create Enterprise Wikis to hold mainly documents for customers, because they have reasonable methods of production and governance. However, this requires that the documents are displayed as attachments (preferably using preview) within actual Wiki pages.


How will the content be maintained?

In customer projects, we often discuss how content which is suitable for Enterprise Wiki differs from news content: Wiki content typically has less (or no) actuality, is not editorial in nature, and is meant to last (much) longer.

The last point means that it is important to consider the governance of Wiki content. While news articles usually fall out of interest pretty quickly, and thus fall into obscurity, Wiki content needs to be found by users over a long period of time.

Content which ends up as files in document libraries tend not to be maintained in an organized way unless it is stored in an Enterprise Content Management System (ECMS). While SharePoint can be an excellent ECMS, when it comes to Wiki a more manual maintenance system is usually employed.

Questions for governance of Wiki content:
  • Can anyone update the content, or should content maintenance be limited to a group?
  • Will the content generally be updated according to a schedule?
  • Will the content be reviewed for compliance/updated with fresh data on a regular basis?
  • Will anyone work with the content to improve findability?

It is important to avoid dead content, or content which is erroneous and misleading. Such content will cause employees to not trust the source, and may be a source of frustration. We have seen examples of organizations where people only exchanged content via e-mail or printed copies, because they did not trust the document repositories.

A successful Enterprise Wiki needs to be maintained on a regular basis. Here are some recommendations:

  • All content should have an expiry date. If it has not been reviewed by this date, it should be marked as “possibly outdated” so that readers are cautioned.
  • All content needs a content owner who is responsible for keeping the page up to date.
  • The taxonomy and metadata may need to be reviewed occasionally to ensure relevance.
  • Someone needs to be in charge of the overall content structure. If multiple documents cover essentially the same content, it should be edited and merged into a single document (or as few documents as possible).

​Consider employing a score card for wiki content. This is a checklist which helps content creators and reviewers evaluate the content against a defined list of criteria, so that it is easier to ensure that the content is still relevant and correct.


Summing up

There are many good reasons to choose Enterprise Wiki for business content. However, it is vital to consider what sort of content will be published, how it will be used, and how it will be maintained. When used correctly, Enterprise Wikis will give a huge return of investment in the form of usable enterprise content which will last a long time.


If you liked this article, you might want to check out our piece on

Editorial Publishing in SharePoint​.