Introduction
One of the common issues I see when companies have ‘had a go’ at implementing SharePoint for document management is that, understandably, they have missed some vital features which would help them. This article will cover several aspects of the challenges and argue why the proposed approach helps users.
Topics Covered
Simplified Security Model for Editors and Readers
Document Classification – Content Types and Column (importantly, why we should)
Document (Office) Templates
Search with Refinement
The Problem – Proliferation
All too often information, documents, are siloed by organisation departments or teams. For example, the Human Resources department will have a library that contains their Policies and Procedures, likewise IT and we see the same for other departments. This approach makes securing easier, and sure it’s easier for the editors to maintain the documents. The person it doesn’t help is the User, the person trying to track down and find that vital policy. You might argue they have got search, but is it right that they can’t simply navigate and files and have to rely on search?
Definition – Company/Organisation Documents
By definition, all company documents, in my view, are 'ALL documents that should be read by EVERY employee'.
Solution Analogy
In all the years I have worked with clients on SharePoint projects there was one particular client I had no problem explaining my approach to working with company documents. The analogy I have always used to explain my approach to clients is a library, not a SharePoint one, but the one we get in our local high street that contains physical books.
This one client and the lady I was meeting, worked in the companies library. Yes, they had their own library with books. Okay, so it wasn’t nearly as big as what you might see on the high street but it was perfect to explain my analogy.
When a user enters a library (still not SharePoint - yet) there is organisation where books are categorised in way to make it easier for users to locate. One library, organised, is the key to success.
So why, when using SharePoint do I see so many libraries, and to make matters worse those libraries may not even be in the same sites. Who are we trying to help here, certainly not the user simply trying to locate information.
Before we begin, check we have the right tools
Before we begin any self-assembly project, no matter its size, we should first check we have all the components needed, including the right tools.
One document Library or Document centre
Site Feature/s Enabled
Content Types (CT's) and Columns
A search centre. Alternatively, I’m a big fan of PnP Modern Search which you can get from https://github.com/microsoft-search/pnp-modern-search
Approach
This approach works for all versions of SharePoint, however if you are still using 2010/2013 Foundation, then a slightly different approach is required.
Security
My start point is always Security, because if we get that right then everything else will nicely fall into place. If you leave security until last you might find you have to implement a horrible security model that might involve securing individual items and that becomes an admin nightmare.
What we do know is this library is intended for All Users to Read content. That’s our first permission level that we set at the library level, if it’s not already set at the Site level. Use the ‘Everyone except external users’ for example.
Next we think about the Editors. If we consider each department / team is responsible for editing their own policies, procedures etc then we need to define a structure whereby users within a team can edit documents, but only their documents and not those of another team. To achieve this, I create a structure that maps to permissions. The image below shows a library that has a Folder (Document Set) for each department. I’ll come on to Document Sets later, for now just think of them as what they are – a Folder.
Document Library using Document Sets
A better alternative to SharePoint folders
We now have a structure that we can start to implement our security. Personally, I would create some SharePoint groups that map to each Department and then add the appropriate Users / Active directory (or Azure) groups for those editing the content for that department.
We can then break the permission inheritance of each department folder and assign the SharePoint Group for that department giving it Edit permissions. Remove any other groups but keep the Everyone… You may want to leave site owners.
Document Classification
To start, what is document classification? It’s a combination of document types e.g. Policy, Procedure, Guide… Additional classification can be achieved by using either out of the box columns or creating custom columns.
Why classify documents? Again, while we might not be making things easier for the editor, those we are trying to help are users in trying to find the documents they need to do their jobs. We can see the benefits later in both navigating the library but also search.
Information Architecture
We need to identify the content used within the library to decide the content types to be used for each. This is where it can get a little interesting, occasionally we’ll have several departments that might need to use the same Content Type, however, they might have different column requirements. In such a scenario there is a solution. There is one other challenge that’s not been touched on yet that may mean departments can’t use the same content types, and that’s the templates – which I’ll come onto later.
Custom Columns
There are occasions we don’t need any custom columns, however, I always assign the Enterprise Keywords to my content types by way of providing a mechanism to tag content. We can later switch these tags and move the information to custom columns.
Creating the Document Content Types and Columns
Should be easy right, however, I’ll cover some techniques I’ve used over the years. As with everything in life, plan.
Document Content Types
Content Types are hierarchical and we can use this to our advantage. I like to avoid making any changes to the out of the box content types, so I create what I like to refer to as a ‘base’ content type that will inherit from Document but will never be used in Libraries, its sole purpose is to enable me to add column/s to it that every inheriting content type will have applied by default. One such column would be Enterprise Keywords. Here’s a representation of how that might look:
Base Document content type. Avoid customising the OOB SharePoint Document Content Type.
We can now start to create our content types for the document library. For example this might look like:
Custom content types that inherit from the Base Content Type.
Remember, both Policy and procedure inherit it’s parents columns. Also, I touched on the fact we might have an need to create Policy content types that differ to meet department needs, well we can do this
Split content types so that you can meet individual department needs.
Where both HR and IT policies share columns we can assign them to their parent (Policy). Any unique requirements for IT and HR can be applied directly on those content types, include templates should they differ.
About Document Sets
By default, Document Sets are a site feature that has to be enabled. Once enabled the Document Set Content Type will appear with the other Content Types.
Document sets are like folders but with special powers. Here are some of the benefits:
Document sets can have their own content types associated to them, overriding the Library content types
We can add columns to documents sets that will be indexed through search
Columns that we add to Document Sets can ‘share’ their values with child items. I’ll describe a scenario later…
Creating the Document Set Content Types and Columns
I follow a similar pattern by creating a ‘Base’ that will inherit from the out of the box Document Set content type. From there create one document set for each department. The reason for having one document set per-department means we can assign the document content types to each document set that the department needs rather than all of them. That said, if we need to add one later, you can.
Base document set content type and department content types.
Like with the document content types we can add custom columns. One column I like to add is the department name, which may seem strange as we’ll provide that when we create the Document Set in the library. However, the intention is to ‘share’ that column with the documents within the document set and thereby auto tagging everything with the department document set. You can use an out of the box department field for this.
Adding the Document Content Types to the Document Sets
This is a fairly simple process of opening each Department Document set in turn and from the document set settings we can add the content types we want to the ‘Allowed content types for the document set’.
Building out the Library
Hop over to our library we can add the content types to the library via the library settings page. You may, through advanced settings, have to enable content types. Once done you only have to add our Department document set content types. You can add the others but SharePoint will sort this out automatically for us when we create the Department document sets within the library.
With the document sets added, jump into the library and from the New button you’ll see our Document Set content types. Select the first department, set the name to be the name of the Department and if you added a Department column that’s shared with the content, then set that too.
With all the departments document sets added to the library we can now go back to the library settings and hide the Document Set content types. They’re not going to be used again so we can hide them from the New drop-down.
If, back in the library, we open one of the department document sets check the New menu we should only see the Content types associated to the at Document Set. Don’t worry if you missed one. Just remember, if we want to make changes do them at a site level and let them ripple down to the library.
The image below is of an example setup, I often use the company initials which have been redacted in the image below.
Site content types, Document and Document Sets.
Permissions
With the Department Document sets in place we can now break the permission inheritance and make sure that everyone had read, the editors group has edit and if Owners groups should be assigned then that’s added too.
Custom Views
I often find that views will need to be created on a Department/Business Area basis typically because they have different columns. Start by creating views to get their columns required on the views.
Create a flat view by removing containers (Folders) and flatten out the content.
Add Views to the Document Sets
If you navigate to the Library Settings and click each Departmental/Business Area Document Set Content Type, it will display the Content Type Settings. In the Document Setting pick the View you want to use for each container. You can't do this on the CT's at Site level because it won't know of the views!
Search
This is important as we need to wire-up our search result pages so that the refiners can use Content Types (SPContentType) or any custom columns we created. The out of the box owsTaxIdkeyWord column is not refinable, so you’ll need to add your own Refineable string property that uses owsTaxIdkeyWord to the Search Schema.
If you chose to use PnP Search, and I strongly recommend you take a look as it’s much nicer with the modern UI. There are quite a few blogs on configuring the PnP Search web parts and setting up refiners which can be found with a quick google search. More here on PnP Search https://github.com/microsoft-search/pnp-modern-search
Templates
A simple feature that so many organisations miss is the use of Office (Word, Excel…) templates, at least, using templates and associating them with Content types. I’ll do a separate blog on some of the trick I’ve learnt with Word templates, however, to make things join up nicely I like to do the following…
Firstly, I create another document set, Templates, that inherits from the Base Document Set. Then I assign all the content types to it. Next I added to the library and then within the library I click New > Templates Document Set and added it.
Assuming we have the templates already, I then upload them to the Templates document set, and for each of the template files set the appropriate content type. What this does, under the covers, is set within the template the Content Type ID. Now, when a new document is created from the template that ID will be persisted and when the file is saved to the Library it will default to the correct content type.
Lastly, should users use the New menu in the SharePoint library we want to make sure the get the template. To get the template URL I select the template file within the library and display the information panel, from there click icon next to Path to copy the URL.
Link to file
I then go to the site content type and set the document template from advanced settings:
Set the content type document template to the file in the Templates Document Set
Notice the host portion of the URL has been removed https://tenantname.sharepoint.com keep the path relative.
OneDrive Synchronisation
For the content editors I get them to sync using OneDrive the Templates folder (Document Set) including their Department folder. Sure they can sync all the other folders too but they’ll be read-only.
Important: If you have a required custom column on the library the sync will be read-only, which is really annoying but it’s been like that for as long as I can remember.
Recap
My approach was about providing a single location for users to locate company documents and be able to filter and/or sort content purely by navigating the content. However, if they wanted to use search they could and they would still have the refiners to filter the search results.
Editors could only create and edit content in their folder (Document Set).
Content would be automatically tagged using the Dept. column which would be inherited on documents based on the Document Set column.
Final Word
While it’s straightforward to do this using the browser UI, my preference is to build this out with PowerShell. It provides me with a nice way to automate the process and tailor the script as and when I need to tweak it.