This document described collected best practices for using SharePoint as a web content management platform to publish company policy documents that will be visible company-wide to your organization.
The information provided here assumes use of Modern UI for SharePoint. However, given the many years we have been providing SharePoint consultation, we may occassionally make reference to "classic" SharePoint features. Please understand that some such features are no longer available in Microsoft 365 or may have changed substantially over time. Thus, we only recommend the use of classic sites under very specific circumstances.
While familiarity with SharePoint is helpful in understanding this document, it is intended for executives, IT / project managers, and business analysts. The concepts described here do not require any specific technical expertise within the SharePoint platform.
If you require assistance with implementation of these best practices or SharePoint in general, you may reach out to us via https://nimbus.liquid-hg.com/support/. (If you do not have a Liquid Mercury account, use the contact information provided to request one.) We offer our SharePoint expertise through a variety of support plans and engagements.
Map What Policies You Will Create
Perhaps you have existing policies already that you wish to move from an existing website into SharePoint. Or, just as likely, you're only getting started and have not yet developed the policies you intend to distribute to employees.
Either way, it's OK if you don't have all the content yet. However, it will be very helpful to identify what policies you intend to publish, how detailed / thorough they must be, and what purposes or requirements they satisfy.
For example, are you posting employee policies to meet regulatory or compliance requirements in your industry or to strengthen computer system security? Or is this effort more about answering employee HR questions and clearing up unwarranted confusion?
Here are some examples of different types of policy documents you may consider:
- Employee Handbook
- Time Off and Vacation Policy
- Remote Work / Work from Home Policy
- Benefits Statement and Eligibility Policy
- Sexual Harassment Policy
- Social Media Use Policy
- Client Information Confidentiality and Non-disclosure Policy
- Computer System Use and Security Policy
- Standard Operating Procedures Manual
- Branding Policy and Style Guide
Create a Team, Plus a Separate SharePoint Site
Likely you may already have a policy team in mind. Of course, We don't mean just a team. We mean an Microsoft 365 Team.
You will need a home for your internal drafts as well as the final version that faces employees. It's very important to keep these separated to prevent draft policies from leaking to employees before they are finalized.
The simplest and easiest way to implement this separation is to create a Private Team in Office 365, which will come with its own private SharePoint site on the back-end. Of course, you could also do this by creating private Libraries within a public facing site, but there are several good reasons to avoid this, including added complexity and the risk that some content may leak through if not properly configured.
Creating an Office 365 Team has several advantages over simply creating a stand-alone SharePoint team site:
- It will simplify management of security and access to draft versions.
- It allows for chat discussions, teleconference meetings, and scheduling among the members of the policy working group
- Word, OneNote, and SharePoint can be easily launched within Teams using methods already familiar to its users that make composing lengthy master draft documents easier.
- Every Team includes a SharePoint site, offering the best of both worlds.
Once you have the internal collaboration site established, you'll need a way to make the final versions of your policies accessible for employees on the web.
You may be tempted to simply add these resources (called Page Libraries / Wiki Libraries) to the SharePoint Team Site that was created with the Team, and then publish your content there. However, doing so would require you to make the Office 365 Team a Public Team, accessible to all the users in the company. Using the second method is certainly more technically elegant, but requires more knowledge of SharePoint, customizations, as well as vigilance (and testing) with respect to security and access. It would be unadvisable in terms of limiting access to discussions, meetings, and drafts.
The recommended option is to keep the draft Team private, and create a second SharePoint Site that's readable to everyone in the company.
Note: for technical reasons, it may not be wise to use Communication Site template for your publishing site. In certain cases, you should use the Team Site template instead, then customize it to fit your needs. This will depend on your functional requirements for things like navigation, content approval, etc. You can start a conversation with your SharePoint SME to discuss business requirements and different technical capabilities.
Compose Draft Versions Using Word or OneNote
Most policy documents are long-winded tomes that work equally well as soporifics as they do for information sharing. The benefits to moving these into SharePoint web pages are to make the information easier for employees to access on mobile phones and facilitate searching for relevant passages.
However, that doesn't mean that you should necessarily rely on SharePoint as a composition tool.
SharePoint tools for basic spelling, grammar, and proofreading are not as robust as those in Word - or even OneNote. Company policies are a big part of the impression you make on your employees. You can avoid embarrassing typos and potentially problematic or non-inclusive phrases simply by starting the process in Word.
Also, while SharePoint certainly has some tools for collaboration, it leans very heavily on the Office suite to provide tools like real-time collaboration, track changes, change-by-change approval, etc. Staff familiar with drafting complex contracts, proposals, or policy documents will be familiar with these features and likely to expect their use.
For example, track changes can be used to assist staff in the creation of a "What's New In This Version?" FAQ which is a traditional feature that companies provide each year, so employees do not need to re-read the entire policy. It can also be helpful to develop the document structure (including table of contents) using Word, since most policy documents can be quite lengthy and they may change radically within their early development and the next few years afterward.
Suppose Word isn't your thing, and you just want to get things done as quickly as possible. We'd like to suggest OneNote as a possible alternative. OneNote allows multiple people to work together on a document or passage at the same time, while allowing content to change quickly. OneNote Notebooks can be added to a Team or SharePoint site with minimal effort, and many SharePoint site templates include a OneNote notebook by default. Many large-scale publishing projects have been successfully completed by starting in OneNote, then moving to Word, with final publication in SharePoint or other sites the web, such as WordPress.
To securely add either a document library (including Word docs) or OneNote to your company-wide-facing SharePoint policy web site, please request these functions from your SharePoint admin.
Overcoming Formatting Issues Converting to Web Pages
How does one go about moving content between all these applications and tools? Does it require any special knowledge? Not really. Unless your document has a lot of images or figures, a simple Copy-and-Paste approach at the appropriate time is all that's usually needed.
You may be thinking that Word is pretty frustrating way to create clean web pages, and you'd be absolutely correct! Many articles exist online (such as this one: How to Convert a Word Document to HTML) describing the limitations of using Word to create web content.
Admittedly this is less often an issue in Modern UI based sites than it was in classic SharePoint, but it can still be pretty annoying to paste your policy document into SharePoint and find that it now has an unreadably tiny font size.
You can create clean HTML copy using a tool like HTML Cleaner. This free website can be used to remove 99% of the annoying cruft created when pasting copy from Word or OneNote. With default options, only FONT tags remain to be dealt with. (Modern versions of Word typically use the Style attribute rather than FONT.) We also recommend checking "Remove Empty Tags" to further clean the copy before posting to SharePoint.
Once you have clean HTML copy, you can paste it into a SharePoint Page using the View Source button. Simply open the HTML source dialog, paste away, and then save/close the window. Your new and clean copy will appear right there in the WYSIWYG web page editor. Simply Save your Page and then continue making edits is you wish. (Please note this approach only applies to classic SharePoint pages. To paste HTML into Modern SharePoint, please copy it from a WYSIWYG editor, or request support from your SharePoint admin.)
Optionally Compose Directly in SharePoint
Indeed, SharePoint offers some very reasonable options for making quick changes to web pages, with robust controls for managing the process of review, approval, and publication. The ability to edit live web pages exists in features SharePoint like Wiki Library, Page Library, and Communication Sites.
So, you may be tempted not to bother with the step of creating any Office 365 Team, and simply do all the content creation and editing directly in SharePoint itself.
If you go this route, understand that you'll be missing out on tools that will help to make the policy working group more productive. SharePoint itself doesn't provide any tools for real-time collaboration, like meetings and chat. Teams, as the modern replacement for Skype for Business, is the tool that provides these capabilities (along with accessibility from within Outlook).
So, you likely want to create a Team regardless, even if you don't plan on creating any draft documents (or web content) in it.
There are other reasons you may wish to avoid creating drafts directly within SharePoint, which we'll touch on as needed throughout the rest of this article.
Adding Images to Content
While most official policy documents do not contain any graphics, the need may come up from time to time. However, graphics can be a very effective tool in shaping opinion and driving adoption. Truly exceptional Intranet experiences will use imagery to reinforce concepts, help maintain the reader's attention, lighten the tone, reinforce serious points.
It's important to consider how SharePoint stores and manages images very differently than tools like Word and OneNote. Instead of images being embedded within individual documents, graphics files are typically first uploaded to a Document Library (such as the Image Library or Site Assets Library), and then included as content in Web Pages.
This method extends the Publishing and Approval process such that each image has its own review and revision management process, thus allowing for needs like ensuring that the company has only used properly licensed images. It also allows for images to be scaled up or down in size, so the final page image may be a different resolution than the uploaded image content.
The image management capabilities of SharePoint are quite robust, but fortunately the default settings are relatively lightweight and east to manage. Modern UI page content will upload images into subfolders under the Site Assets library, so you don't need to worry about where they are stored.
Therefore, although you are not required to do so, you can safely develop your content in more robust authoring tools and copy it into SharePoint when you are ready to publish it.
Specific capabilities vary greatly, so we did a thorough analysis that you can refer to our knowledge article, Adding Images to SharePoint Content, posted here on Nimbus.
Here's a quick reference for methods to upload images in Modern SharePoint pages:
- Upload single file using Insert Image / add Image Web Part
- Drag single image file from a PC folder into SharePoint content. (Dragging images from other sources isn't likely to work.)
- Copy and paste content/images works in PC applications like Word and SnagIt, but not in UWT/Electron based web-apps-on-the-PC like OneNote or Teams.
- Copy and paste content/images works for some Office 365 web apps like OneNote for web, but not within Word for web. Be careful about URLs when pasting HTML into SharePoint, as the end user might not have access to the image at the source location.
For best practices, limit how much you rely on adding images one-by-one. When copying content from other applications into SharePoint, use the web version for OneNote and use the PC App for Word. Avoid directly dragging-and-dropping content from both sources, since this only works well for files saved to your computer. And lastly, be mindful about copying content with image URLs that point to files that your end-users cannot access.
Avoid Wiki Page Anti-Pattern
While creating content, we observed an unusual behavior in Modern UI SharePoint sites. While adding new pages, we were directed to use the legacy "classic" page editor. This editor is still functional, but has a lot of known issues and weird behaviors - including messing with the page's HTML code in ways that can destroy content on modern websites.
It turns out the cause of this is the legacy "Wiki Page" page layout. The legacy "Site Page" layouts produces a modern UI, albeit with fewer options than usual.
To Avoid creating Wiki Page by mistake, simply remember not to select it if you somehow are given the choice to do so. Use the correct methodology to create Modern Pages, and everything should take care of itself.
How to Create Modern Pages
By far the BEST way to create a new page in a modern site is directly from the New button on any existing page, including the Library Pages list or the site's Home page.
Pages created this way are made available with one of three out-of-box modern UI page templates: blank, visual, or basic text.
- Blank is what it sounds like, there is no base content and you can add anything you want to the page, within reason.
- Visual includes some stock imagery at the top and bottom of the page, which you can easily customize. Text is presented as a single column, suitable for most mobile devices.
- Basic text provides a top-of-page banner you can customize, and two column text in a smaller font. In some cases, it may be preferred by users who are using a PC to read the content and should scale to single column for mobile users.
- Other page templates are available. Consult with your SharePoint SME about development designed or third-party templates.
Creating Pages from the New button does have some downsides. For example, the pages are always created with the Site Pages library. Further, the ability to have multiple Page Libraries in site has been removed from the Modern UI.
If your plans involve having one logical container per policy document (see "Create a Centralized Policy Site" below for reasoning), then you may have to resort to either sub-folders or separate SharePoint sub-sites instead. Each of these come with their own pros-and-cons, and there will be steps that need to be completed on the back end, so consult with your SharePoint admin if this is your plan.
Create a Centralized Policy Site
You could create a separate SharePoint sites for each policy, but this is likely to get out of hand quickly. Tracking which site policies belong to which site may lead to a lot of extra questions and requests for support.
Using a single site to publish policies can also help you integrate those into your company's overall Intranet strategy. Within SharePoint, the modern practice for creating an Intranet is to create a SharePoint Site called a Communication Hub, and individual Communication Sites or Team Sites that will be joined to it in order to provide a unified site navigation experience (generally shown in the top navigation bar).
Having a single site means significantly less provisioning work involved in adding new policies later. It also means that you can have one link in top navigation for "Company Policies" instead of multiple site links (though you can still easily add individual policy links if desired).
Note that you might have reasons for not putting all your policy eggs into a single site basket. One justification for this would be different permissions for different teams that are tasked with keeping the policies up to date. In that case, the best practice would be to create individual sub-sites under a top-level policy site (or Site Collect for the O.G.). Using sub-sites allows for the required functionality without overly complicating the relationship between the policy site and any current or planned Communication Hub site.
There are some technical considerations. Firstly, note that as mentioned previously Modern UI has removed the ability to create multiple Page Libraries in a single site. This would have been an option in classic SharePoint, and one we often recommended.
The available options today are to use sub-folders in the Site Pages library, or to create one sub-site per policy document. Using folders is preferred if the permissions and navigation will be consistent throughout all policy pages. Using sub-sites is the way to go if you have multiple policy teams or want custom navigation (Quick Launch) within each individual policy.
Either way, some changes will be needed on the SharePoint back-end. Folder creation is normally disabled by default and will have to be turned on. There is a set of options and configuration settings to consider upon creating each sub-site. In either case, starting a conversation with your SharePoint admin is the recommended first step.
Whenever you have multiple people with access to make changes to your policy site, ensuring that document versioning is enabled is a must.
Versioning retains a copy of the older policy versions any time there is an edit to the policy.
This provides a running log of what the official policy was on a given date, as well as which date the new policy became effective. This can be quite useful later if there's ever any question (or dispute) regarding company policies.
It also ensures that when two or more people are making edits to a Page in SharePoint, their individual changes will not be lost - even if they save overtop of one-another.
Fortunately, versioning is enabled as a default option in Modern SharePoint. However, there are settings you may want to consider changing upon creating a new site.
For compliance reasons, you'll want to have your SharePoint Admin enable both major and minor versioning, and do not limit the number of major versions that are retained. It would be unadvisable to allow older policy versions to expire and be deleted, just in case there's a legal reason they'd be needed at some future date.
It's perfectly reasonable to limit how long minor (draft) versions will be kept, since this information isn't very useful once a new final draft is approved. However, it's also OK to keep these indefinitely. Don't worry about the file storage requirements, since text-only web pages are very small and even unlimited versions won't take up a lot of space.
Enable Publishing and Approval
Publishing and Approval are different than Versioning. The purpose of publishing process is to establish which version of the policy is viewable to the public and which is viewable to only the policy working group. The Approval feature allows publication workflow to flow through a manager or small group of editors.
Publishing capability limits the visibility of documents based on the version status. Documents are generally checked-out for editing, then checked-in when finished, either as a Major or Minor version. Only those with Edit or Approve rights to the documents may see Minor versions.
In publishing scenario, Approval is only triggered when a major version is checked in. So, those responsible for creating content will need to be trained on this pattern. Once approved, the check-id content is now available to all users.
Basic approval in SharePoint will allow a series of individual people (serial approval) or a group (parallel approval. A group can be either all-vs-none or x-or-more to approve.
Best practice in SharePoint is to maintain reasonable expectations regarding out-of-box approval processes. Many an organization have gone down the rabbit hole of trying to make SharePoint approval workflows into something they can never truly become. If you have complex workflow requirements, such as multi-stage interdepartmental workflows (e.g. internal team approval, per-department approval, legal team review and approval, etc.) then you'll need a more robust solution such as Power Automate to implement these needs. Consult with your SharePoint SME about building these.
That being said, there are some levers that can be tweaked through Site configuration - and some pitfalls that must be avoided. Consult your SharePoint Admin or Site Owner to discuss available options and their impact on Site behavior.
Avoid Modern UI with Publishing Feature Anti-Pattern
Here's something important that your SharePoint Site Owner or Admin needs to keep in mind. You may require the functionality of publishing and approval, but you should never activate the Publishing Feature in a Modern UI site. That's because the feature will break all the Modern UI pages on the site, and replace everything with classic site pages and templates.
Instead, your admin will need to enable certain functionality by hand, in order to replicate the capabilities of Publishing Feature without creating this problems. Specifically, major and minor versioning and check-in / check-out settings on the Site Pages library should be enabled to reproduce behavior similar to the legacy Publishing Feature. Optionally, such versioning and check-in options should also be enabled on the Site Assets library, so long as the business process demands such vetting on images as well as prose.
Use Dual Logins for Content Creators / Admins
It's important to understand that SharePoint will render content from Libraries and Lists based on the security permissions given to each individual user.
In practical terms, this means that those users who have Site Owner or Content Approver permissions will see documents and images (or versions of them) that ordinary users can not see. Authors will also be able to see draft versions of their own documents and images, even if those have never been published.
So, for example, if a page author has uploaded some images to be used on the site. They create a page using those images and then publish it. Even if the page is approved, if the images aren't also checked in and approved, then they may not appear in the publicly viewable version of the document - or they may appear as broken images.
It's important to understand that detecting such problems is made more challenging by the way permissions are assigned to complete authoring, approval, and admin tasks.
This isn't so much a technical issue as a problem of workflow and process.
The solution to this is to give privileges users two logins, a regular user login with ordinary view-only permissions to the site, and a "super" or "priv" login that has the enhanced permissions needed to complete their job duties as needed. This is common practice for Global Administrators and SharePoint Administrators, but may be a new concept for some business users.
While such practices are common in large organizations and secure environments, per-user licensing costs may make this an unattractive choice for smaller organizations. An alternative approach would be to assign enhanced privileges to user's standard logins, and create a shared test login that all members of the content team can share for purposes of previewing how the site appears to the rest of the community.
Thus, when the content team need to see the site as other users see it, they will have a ready made means of doing so. They can simply open a private browser (or new container/profile), login as the standard user without any special authoring permissions, and review the site for errors such as unpublished pages or missing/broken images.
Your Office 365 Global or User Admin can create these extra accounts for you, and our sales team can help you explore ways to control licensing costs associated with additional user logins.
Limit Each Page to a Single Topic
When posting content from a lengthy policy document that was drafted in Word, it might be tempting to simply paste the entire document into a single web page. That would be a bad idea.
Instead, we'd suggest that you group content by topic and make each logical topic a single web page.
Why is this? In a word - findability.
Just like Google, Office 365 search works better when documents use language that relates to a specific topic. Terms and keywords that appear in the title of a page will carry much greater weight than those in text, and text at the top of a page will be stronger than passages farther into the document. Burying important terms on page 35 of your policy document will weaken the strength those terms have when people search for them.
So, for maximum findability, break your policy document into pages based on sections that make sense. For example, you may put all the time-off policies on a single page, with a second page specifically for vacation policies.
To limit how much you need to do this, consider placing an executive summary at the top of chapter-documents. This ensures that important terms are listed at least once at the top of the page, while allowing you to draft lengthier sections.
Always Number Your Pages
Breaking larger documents into smaller sections presents its own challenges. You may need to be able to find that section again in the master draft document. Also, page titles may not sort well alphabetically in a table of contents
To resolve this, always prefix the title of the document with its section number, corresponding to the numbering scheme from your master draft.
You can (and should) also add this number a separate field in your Page Library. To accomplish this, please ask the Site Owner or seek assistance from your SharePoint admin.
As for number formatting, we recommend using a decimal number field, but text fields can also be used with caveats. Decimal numbers are the preferred method for inserting new content, because you can always insert a decimal between two other numbers. For example if you already have section 1.3 and 1.4, you can add 1.31, 1.32 etc. as needed.
Things become a bit more challenging if your numbering format works like IV.A.2.c.iii. For one thing, there no native roman number sorting option in SharePoint (or most other systems we know of), so you'd end up needed a separate field to maintain numeric sort order in any case. For another thing, in the above example, there is no easy way to insert a new section between IV.A. and IV.B. (Would that be IV.A+0.5… or IV.A-2..?)
Simply put, it's simpler and easier to start with numbers as numbers. If you must map to a more traditional mixed numbering scheme, we recommend making that an entirely separate reference field apart from the sort order and the page title. Then, you can prefix both numbers, either, or none at the start of the title for each page.
Create a Table of Contents Page
When following the best practice of one page per topic, the number of Pages in SharePoint could get quite large. Putting every page into site navigation is not only cumbersome but would make the site more difficult to use.
Fortunately there's an easy fix for this. Create a Table of Content page for your site.
To accomplish this, simply create a new Page (like you normally would), and add a List View Web Part to it that points to the Site Pages Library. Adjust the settings to create a View that sorts the Pages by their sorting number (see "Always Number Your Pages" above). That way, the ToC will appear in logical order.
You can also limit the view to show only the page link (without the edit menu and all that other field-cruft that appears by default). It's also worth noting that if you have multiple policy folders, you will need to create a separate View for each, so they can have separate tables of contents.
If you need assistance completing any of the above tasks, please reach out to your Site Owner or SharePoint Admin for help.
ToC has another advantage over using Site Navigation / Quick Launch. It updates automatically. There's no need to go into the ToC and add each Page. They will appear as they're approved and published. This frees up Quick Launch to be used more strategically, as we mention next.
Add Important Pages to the Quick Launch
As a departure from structural navigation from classic SharePoint, links on the left hand navigation (Quick Launch) in Modern UI for SharePoint sites are managed manually. Though Site Owners are given a choice to add links to new Libraries to Quick Launch, SharePoint can no longer be automatically configured to display the pages / contents of each library, as used to be possible through Layouts and Master Pages.
However, let us stick to what is simplest and most cost effective, which is to use the Quick Launch as Microsoft envisioned it. Keep the links in Quick Launch down to those which can be easily maintained manually by the policy team, adding only those which are of special interest or significance.
As such, the Table of Contents should be the first such special link added here, allowing users to find any policy page they need. Add any special pages of interest to the Quick Launch, such as the intro page for each policy section or chapter - or policies that receive a lot of inquiries, require emphasis from management, address systemic problems, etc.
Create Sidebars for Related Topics and/or Pages in this Section
Often, page authors might be tempted to add links at the bottom of each page. For example, this might be used to direct users to the next section, or to call to attention related policies, "see also" documents, or links to contact HR and the like.
While putting these at the bottom of the page is fine, there are other ways to take advantage of the visual structure of the web page itself. Page authors can change the page layouts to leverage multiple columns or sidebars.
As an example, in a page with a right-hand sidebar, links to the other pages in the current section could be provided for convenience. The only downside for this is that such content would have to be copied to each page individually, as it is unique to the page and not part of the overall site navigation and look-and-feel. To make this easier, authors can take advantage of Content Snippets to embed the same content in many pages, while only needing to edit it in one single location.
If such functionality would be useful to you, please start a conversation with your SharePoint SME.
Close Your Comments
By default, Pages in SharePoint have comments section enabled at the bottom of each page.
While this can be useful in some cases, unless you want "Boo!! This policy sucks.", "Imma freshen up my resume" or other unhelpful comments or complaints to become the norm, disabling comments on official policy documents is probably for the best.
Remember that while disabling policies on page creation is easy to do, it's also easily missed. Don't be upset if your authors accidentally leave comments enabled. Instead, talk to your SharePoint admin about disabling comments at the site level or scheduling periodic checks to disable all comments on policy libraries.
If you want to receive feedback about policies, consider other tools like a Microsoft Forms Survey or anonymous submission box as more appropriate methods to accept constructive criticism while maintaining respect and corporate discipline. Any of these options can also be raising in such a discussion with your SharePoint SME.
Set Review Dates
Policies are only as good as times that made them, and things can and do change over time. Perhaps the team that created the original policy is no longer working at the company, priorities have changes, or there's a need to address a specific issue, or stay competitive for talent.
No matter what, stale policies are to be avoided. An effective policy working group will meet at least once yearly - or perhaps quarterly - to discuss what additions or changes are needed. It will include members from different disciplines (HR, C-level, key departments).
However, one thing that's often overlooked is while policies might be going stale. This is something SharePoint can be of great assistance with. Data exists within SharePoint to show which pages have not been modified in a long time or those that may not be viewed very often. Much of this information can be made available to decision makers prior to policy meetings using simple tools such as a custom View.
Whether you're a business owner, IT boss, or have been asked to implement SharePoint on behalf of your team, we truly hope you found these tips useful as you begin your journey of using SharePoint to manage company policies and other Intranet content.
You can find lots of articles like this one on Nimbus, our knowledgebase and customer service portal. Some content is by permission only, so if you don't already have an account, please request one from us. As always, our team of SharePoint experts are here to support you when you need help, so don't hesitate to reach out and start a conversation. Together, we'll Set Course for Cloud Success.