This series of posts I will discuss how SharePoint 2013 Document Sets and other SharePoint features can be combined to provide a robust solution for managing numerous related documents like those related to activities such as project management, legal cases, contract negotiations, business proposals or whatever.
In this set of articles we will create a typical corporate Project Management Office (PMO) solution that involves structuring and grouping all document artifacts related to a given project together with as little administrative overhead as necessary.
The sub-goals of satisfying this requirement are also:
- Use out-of-the-box SharePoint (no-code capabilities as much as possible)
- Centrally initiate new projects and ensure all have common meta data, document structures and templates
- Populate the project with standard PMO document templates such as Project Charter, Status Reports etc.
- Automatically associate all project documents together
- Search, aggregate, filter Projects within and across Site Collections
- Leverage retention policies so projects can be archived for safe keeping
Create Content Types
Document Set Content Type
Firstly, we create a “Document Set” Content Type called appropriately: “Project Document Set.” By leveraging the Document Set’s synchronization feature we can achieve quite a bit of automation without code.
The “Document Set” Content Type is an out-of-the-box SharePoint Content Type with special powers for coordinating the properties among the Content Types it manages. This coordination of Content Types allows you to treat a group of Documents as though they are one. The benefit of this is that you can manage an entire groupings of documents as one unit. For, example moving all related documents to a Records or Document Center for archiving.
The image below illustrates the concept more clearly. The green oval represents the Document Set Content Type with Content Types it manages inside. Notice the common fields marked with the red star. The Project Document Set is configured to synchronize the common fields thereby alleviating the burden of requiring the users to complete those fields over and over again with each new document that is added to the set.
There is a design decision here that you will need to make as far as where to define your Content Types:
You can define Content Types and Site Columns in either a single Site Collection or in the central Content Type Hub. The difference is that when defined in the Content Type Hub they are available throughout all the site collections in your SharePoint Farm using the Content Type Publishing feature. Otherwise the Content Type definitions are only available in the site collection in which they were defined. For more information about Content Type Publishing and the Content Type Hub refer to this article.
I’m not going to cover what a Content Type is or how to define them in this article. If you want to learn and understand them start here.
Shared Site Columns
The “Project Document Set” Content Type will have the following fields so those need to be defined in the Site Columns:
- Project Name – Single Line Text, Required
- Project Type – Managed Metadata, Required
- Project ID – Single Line Text, Required
- Project Status – Choice
Here you will want some of the fields as required. By doing so you can later use those fields in a Documents Center or Records Center to filing your documents using automatic rules. In subsequent articles I’ll demonstrate how to archive these Project Document Sets using automatic filing rules so I am marking the Project ID, Project Type and Project Name as required.
Project Management Document Types
Next, we create Content Types for the various document types that the Document Set will manage. For this I am using a few standard PMP document templates available at http://www.projectmanagementdocs.com.
I will create a Content Type for each document template I downloaded. The Parent Content Type for each of them will simply be SharePoint’s “Document.”
- Charter Template
- Communication Plan
- Status Report
- Work Breakdown Structure
Although I did not do it here, I find it helpful to first create a custom base Content Type derived from “Document” (call it “Project Document” or something) and then derive all the remaining Content types from that. This provides the flexibility of easily adding additional fields to all child Content Types by simply adding columns to be base.
Each of the four Content Types will utilize the same site columns we defined before creating the “Project Document Set.”
- Project Name – Single Line Text
- Project Type – Managed Metadata
- Project ID – Single Line Text
Reusing these same fields is important because, as mentioned earlier, SharePoint will automatically synchronize these fields across all the Content Types it manages.
Here is the completed Content Type definition for “Project Charter.” The other three Content Types will be configured the same.
Associate Individual Content Types to the Document Set Content Type
Now we have our “Project Document Set” Content Type defined along with the other Content Types it will manage.
Configuring the Document Set
To configure the “Project Document Set” click it from the list of Content Types and select Document Set Settings as shown.
Here is where all the magic happens.
Allowed Content Types
The first section called “Allowed Content Types” is where you associate Content Types that the Document Set will manage. Here I have selected a group of Content Types that contains all the PMP project Content Types.
The next section called “Default Content” defines documents that will be prepopulated when a user creates a new “Project Document Set.” This is awesome because at any time an administrator can change or remove a document template insuring new projects will use the latest templates.
To configure, just select one of the Content Type in the dropdown, specify a folder name where the template will reside and upload a document. The document file is mandatory so if you just want to create an empty folder you won’t be able to. (In another post I’ll demonstrate a remote event receiver which deletes the file so the user sees only an empty folder).
Below is the newly created Project Document Set and notice how SharePoint creates the Folder(s) specified in the “Default Content” settings.
Drilling into that folder you will find a copy of each document that was also specified.
The “Shared Columns” section lists the fields in the “Project Document Set” Content Type that will be synchronized with the Content Types it manages. Simply check the fields that need to be synchronized. Not only does the synchronizer work when a new Document Set is created but it also works when you update one of the synchronized fields. For instance if, after some time a project name is changed it can be updated on the Document Set and all child items will also be updated.
Continuing from the previous image; below are the properties of the files where the Project Name, Project Type, Project ID fields synchronized from parent Document Set.
Note that word “Frozen” in the Project Name is misspelled. To clean that up all that is necessary is to update the Project Name field with the correct spelling in the Project Document Set and SharePoint will synchronize that change to all the child Content Type’s it manages!
There are two primary issues with this out-of-the-box Document Set functionality that I don’t like. I found no way around these so I eventually ended up created a Remote Event Receiver to clean them up.
The first issue is the Content Type SharePoint assigns to the sub-folders. Remember in the Document Set Setting’s “Default Content Types” section, folders and templates can deployed when a new Document Set is created. Here I noticed that the assigned Content Type is the “Project Document Set” itself which means the sub-folders are themselves “Document Sets” and not the typical “Folder” Content Types that you would expect. Having the sub-folders assigned to my “Project Document Set” Content Type is problematic because we will get incorrect search results when querying the system for Projects.
Not only was the Folder Content Type wrong but I also noticed that the Project Name, Project ID, and Project Type fields are not synchronized. I experimented by attempting to allow my “Project Document Set” to also manage the “Folder” Content Type but it cannot be selected in the “Allowed Content Types” section of the Document Set Settings. As mentioned above I eventually developed a Remote Event Receiver to update the sub-folders so that they were “Folder” Content Types and also populated the values correctly.
The next big undesirable I found when working with Document sets was the “Name” field of the Document Set Content Type. Apparently, “Document Set” Content Types are derived from the “Document Collection Folder” Content Type which in turn are derived from “Folder.” This means that a Content Type is basically a “Folder” and it has a Required “Name” field. As such, the “Project Content Type” also must have a “Name” Field which is redundant to the “Project Name” field we defined. My solution was to have the user simply enter the Project Name in the “Name” field and then the remote Event Receiver would copy the value from the “Name” to the “Project Name” field.
In subsequent posts I’ll demonstrate how to tune the search engine to display and filter these Projects and how they can be moved in their entirety to a Documents or Records Center using automatic filing rules..