Originally written in 2015, but never published. This blog (and series) discusses efficient SharePoint site management through the establishment of standards. It emphasizes the importance of creating a standards page to enhance user training, ensure consistency, and simplify maintenance.

Fast forward to 2025, unfortunately is both still relevant and obsolete. It is obsolete because Microsoft changed the underlying functionality of SharePoint. It is still relevant because Standards are important to ensure effective Communication and Coordination (see 4C’s: Communication, Coordination, Control & Command).

This is the third in a series of blogs detailing my experiences and uses of the tool.  The first blog, SharePoint 101, provided some context and a ‘fictional use-case’ which the following blog is based on.  The second blog provided a discussion on creating ‘How-To’ Desk-Reference pages.  I want to get into pages that support these pages, otherwise known as Infrastructure or INFRA-Pages, but first a few blogs on some standards used in creating and sustaining SharePoint sites.

The first is this blog, which lists the standards used in wikis.  By establishing the standards page before creating any other page or SharePoint lists you will save yourself time.  Firstly, the standards makes a set of decisions for you about common attributes that will appear numerous times throughout the list.  Next, because you are using common fields, training for the end-user becomes simpler.  Finally, because of these standards, sustaining a site that you have created (or even better, someone else has created) becomes easier.  In other words, Quality is Free but it is not without effort.

I use the following standards in setting up a site:

• Naming conventions (this blog)
• Templates to create new pages (this blog)
• Data Dictionaries (future blog)
• Permission and Access (future blog)

Stick with me, I promise though, if you get to the end of the above blogs you will save time – over the long run – on maintaining SharePoint sites.  The previous blog introduced some of these standards when creating ‘How-To’ pages.  Nevertheless, some of the core standards are worth repeating.

Describe Your Standards

The inclination is to start building a SharePoint site as quick as possible.  The good news is that you can start building fast; unfortunately the bad news is that you can start building fast.   The result is often a site that has stale content, varying presentation formats, conflicting information and worst – no one uses it.

Thus, go ahead and build – but also plan to either retro-fit to a style guide (described below) or build from the style guide initially.  Fortunately if you start from a site template and even from template-pages (discussed in the next standard), you can build quickly and consistently.  The following standards are a taken from one of the sites I currently run but represents standards I have used across four different organizations.  My suggestion is that you create this as one of your first wiki pages:

SharePoint List Standards

Types of SharePoint Lists

SharePoint lists are used to manage a single-source of truth for a variety of data and information.  Generally lists fall into one of the following categories:

1. Control or Meta Lists: these are lists about lists and are used to describe the site.  Examples include the data dictionary, access and site structure, wiki library or Desk Reference Image library
2. Structural Lists: these are lists to manage structural information so that such information exists only once (single source of truth) but can be consumed or used multiple times.  Examples include the budget codes, project lists, and contractors.  Structural lists are first described in a control lists and changes are similarly done in a control list and then implemented.
3. Transactional Lists: these are lists to represent business activity.  Such activity typically is created and used once and then is replaced by another record (e.g. a forecast entry is only relevant for one fiscal period as the underlying financial information may change).  Transactional lists rely on structural lists and are described-then-built in control lists.  Examples include: budget planning, planned-projects or forecast entries.

Common SharePoint List Fields

Although the above 3 lists focus on different aspects of an organization business, there are some common fields that may be used through out the lists:

• Current?: SharePoint Column, a Yes/No value which indicates whether an item is current (Yes) or Not (No).  Generally records are never delete or disabled via this flag.
• Your-Notes: a short narrative describing why this record was created. As this is often the SharePoint-lists ‘title’ field, this has the added benefit of creating user orientated text in a field that otherwise can not be empty or null; a default note is provided.
• Comments: Used to collect point in time information about the SharePoint list item. General a multi-line, rich text column type.  The standard description is ‘Narrative not provided elsewhere’ meaning that comments should be the field of last resort to enter information.
•  
• LINK fields: SharePoint has a limitation in that it does not permit a look up of a look up (look for a blog on this, for the moment – just trust me).

Standard List Views

• Current?: SharePoint View using the Current? column, only where Current?=Yes records are returned.  This is typically the default view for the list.
• Population: a data sheet view of only the columns that accept data entry/selection.  For example, calculated, ‘LINK’ or Lookup-Reference columns would be excluded.
• Summary: A summarized view used so that a list can be referenced on a Desk Reference page. Typical attributes are: minimal information/columns, a 10 item limit, no descriptive columns that will cause an item to wrap.
• XLS-[DESCRIPTION]: These are views used to extract information for subsequent use in spreadsheets (e.g. excel, thus the XLS prefix).

Creating and Updating Graphics

Graphics greatly improve the utility of a desk reference/wiki by providing a visual reference.  Without a little forethought, graphics can quickly become disconnected or lost.  Thus all graphics used in a desk reference should be saved in an image library expressly created/designated for that purpose.  Version this list so you can see the evolution of the graphics.  Other storage standards can be defined in the Document Management desk reference.

• PNG is the preferred graphic image format which are stored in the Desk Reference Image Library.
• Updating a PNG file involves the following steps:
  • Open the file in a graphic image editor (e.g. Microsoft Paint)
  • Replace the previous version of the SAME image with an updated version
  • A trick is to open an existing image and saving the image with an updated name per Document Management standards (e.g. no-spaces).

Wiki or Desk Reference Page Names

Page Names use the following standards:

• No spaces, use “-” or “_” instead
• File: Used to define a file, report, etc.
• “How-To”-[SUBJECT NAME]: Used to describe how to perform a business process
• “Infra”-[SUBJECT NAME]: Used to describe a piece of infrastructure such as a SharePoint List
• “Wisdom”-[SUBJECT NAME]: Used to describe an unique event and how STP handled that event, used for future reference.
• “UNIT”-[SUBJECT NAME]: Support Unit specific documentation
• template: Used as a template to create other pages (see below for more on this)

Wiki or Desk Reference Pages General Organization & Principles

Wiki pages are managed using the following principles:

1. Content is created once and referenced many times.
2. Content is assigned an owner who is accountable for the accuracy and currency.
3. Desk Reference content should cover about 80% of the cases; judgement and experience by team members and client managers covers the other 20%.
4. Ad hoc activities are not documented in the Desk Reference unless the manager expects that they may be reoccurring in the future.  If so, the consider creating a WISDOM document.
5. Page Names should be short (8-12 characters), not contain spaces (use “-” or “_” instead) and the name should suggest the content contained on the page.
6. Aliases should be used when referencing pages. Generally the alias equals the ‘Page Title’. (note, an alias is created by inserting a pipe or “|” after the wiki reference, for example: “[[INFRA-BUDGETCODE|LIST OF BUDGET CODES]]”)
7. Page Format, the general format for the page is:
   1. Header, generally containing Home and the parent of the current page (e.g. a page discussing larger subject matter); font = Verdana 8pt
   2. Page Title, what the page explains in a short crips set of words; font = Verdana 18pt
   3. Content, Using style Heading 1 and Body Text Verdana 12pt
   4. Page Body, Should be about 1-2 pages in length (no more than about an 8.5×11″ page double sided).  Graphics are encouraged and should be stored in the image library.  Use headings to make the page scannable. Assign a page Owner who is the staff member is responsible for the page

Template Pages to Create Pages

While the above may seem daunting, one of best way to create SharePoint lists and Wiki/Desk Reference Pages is through the use of templates.  In the context of lists, this will be described in a future blog.  For Wiki/Desk Reference pages, a template page should be a priority when setting up such a SharePoint library.  A template simple contains the skeleton of the pages to be created.