Introduction
A couple of projects I've worked on recently both had a requirement to store company documents in SharePoint, which in itself is not uncommon. In this blog I'd like to share the approach that has worked really well for both clients. I'm not saying it's right for every company but if you're struggling to get started with SharePoint, then this might help you.
Background
There's a bigger picture to the projects I was involved in but I wanted to write-up the approach I took to provide a single SharePoint library for all company documents.
By definition, all company documents are 'ALL documents that can be read by ANY employee'. There are restrictions with maintenance of those documents in that, only the departments or business areas will have the ability to edit and create the documents they own.
Why use a single library? Simply, one place for staff to locate and read documents. I've always advocated that if you can't navigate to find content and instead have to rely on search, then what is implemented is broken.
Approach
This works for all versions of SharePoint, however with Foundation a slightly different approach is required.
The ingredients:
One document centre
Content Types (CT's) and Columns
A search centre but if you already have one then we'll just add a new search results page.
Information Architecture (IA)
I can't stress enough the importance of understanding what content will be put into the library and the need to create those content types and columns. If you don't think this is important or don't have time for this; I don't think this blog can help you!
Document in a spreadsheet all the content types and columns so you can map which Columns need to be assigned to which Content Types. Here's a crude example:
| Content Type | Column A | Column B | Column C | Column D |
|---|---|---|---|---|
| Policy | Y | Y | Y | |
| Procedure | Y | Y | Y | |
| Guide | Y | Y | Y |
Document Sets
I use document sets to create containers for each team. By using document sets I can:
Set permissions to control who can edit
Auto tag content
Set only the Content Types needed for each Document Set.
Create the Columns
Create all the custom columns based on our IA. Be warned that if there is a name clash with the out of the box columns and you think of use the OOB one, then make sure you check it's type. If it's not, then create your own column being creative with name.
Tip 1: Create a column called Content Type Set? which is required. The column is type 'choice', 'dropdown' with a value of 'Yes' but the default value removed. The purpose of this is to ensure that when users upload content they have to confirm they've set the CT and to not let them fall into the trap of the document just inheriting the default CT and getting set as is.
Tip 2: Create a column called Dept. which is not required. The column is type 'single line of text'. We'll use this for auto tagging the files
Create the Document Content Types
Tip 1: Create a Content Typecalled 'Document Base'. This Content Type will inherit from Document and while it will never be published to a library it will have a purpose. Every custom CT identified in the IA will inherit from Document Base. Why? Because if we want to add a column that will appear on EVERY custom CT then we only need to add the column to Document Base and it will flow down. Look at my crude table example above and you can see that Column D is used on all Content Types, therefore this could be set on the Document Base CT and inherited by all child CT's.
The Content Type Set? column gets added to the Document Base CT and therefore inherited by all inheriting CT's.
With the Document Base CT created I then create all custom content types that inherit from the Document Base.
Add your custom columns to the appropriate CT's defined in the IA.
Create Document Set Content Types
Create a 'Document Set Base' CT. As I did before, if we need to add a column that should appear on all inheriting CT's then I can set it once on the Document Set Base CT. The Dept. column we created will get added to the Base Document set CT.
I create a Document Set CT for each Department/Business Area that will maintain content in the Document Centre. My experience has been that it's commonly Departments, HR, IT, Sales, Marketing etc. But that might not be the case for every company.
Talk to your IT team to identify how they work with Security Groups as we can use these groups to map security in SharePoint and simplify our admin. This also helps to identify the Document Set CT's if there is a correlation between the Security groups and the Department/Business Area.
With the Document Sets created we can update each and assign the Document CT's that department needs. You could get lazy here and just put all the Custom CT's on each Document Set but when you've got a lot of CT's it can make the New menu unnecessarily busy. Make sure you remove the Document (out of the box) CT from the Document Set - there is no place in SharePoint for that CT!
We can share columns of our document set with the documents that will be added. Check the box for Dept.
Create and Configure the Document Centre
Having created a Document Centre the first thing we need to do is clean-up (delete) the out of the box CT's. Add the Departmental/Business Area Content Types to the library, with the exception of the Base CT's. I often leave the Link to file CT.
In the Document Centre library settings switch off the 'create folders' option. It's my opinion that if you need folders then you need to go back to your IA to add the missing columns.
Create the Departmental/Business Area Containers
This is a bit weird but it works - so hang in there with me! In the Document Centre Library, on the New dropdown all the Document Set Content Type's we created will appear. Each one needs to be added to the Library and the Name given to the Item created is the Department/Business Area name. In the Dept. column type the Department/Business Name.
The purpose of the Dept. column is simply to tag every document.
Having created a container for every Department/Business Area, go back to the Library settings and update the Content Types and hide them. Those Document Set CT's are no longer needed but they can't be deleted as each is in use.
Enhanced Navigation
It should be on by default but make sure that the Metadata Navigation includes our Custom Columns so users can filter content.
Quick Test
If you navigate into one of the containers in the Library we should see the Content Types available appear on the New menu.
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 on the views.
Create a flat view by removing containers (Folders) and flatten out the content. Remember the 5000 item limit as this could trip you up.
Add Views to the Document Sets
Another quirk. If you navigate to the Library Settings and click each Departmental/Business Area 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!
Permissions and Security
This alone is a pretty big topic but for simplicity I'm going to create a Departmental/Business Area SharePoint group for each. You may already have these. I then add the AD Security Groups to the SharePoint Groups as I want IT to manage the security.
I'll assume the Site Visitors group for SharePoint already has Authenticated Users so anyone who is a domain member has access. If you're SharePoint Online then it's 'everyone except external users'.
On each of the Containers in the Document Centre I'm going to break the inheritance and remove ALL groups with the exception of two:
Site Visitors who get Read access
The Department/Business Area for that container who will get Contribute.
Note: I often add a new permission level to SharePoint called Contribute with No Delete. As you might imagine, I copy Contribute and remove the Delete permissions. I may introduce a third group on the Container where managers have Contribute but content editors only have Contribute with No Delete.
And breath; we're not done yet...
At this point I'd get some content added to our library as this will help us with the next part.
Search Schema = Refiners
All those fantastic columns we created from the IA we can get them added to the schema in the Search. We can then use them as refiners in Search.
The reason for having some content in the Library is so that we can crawl the content and check that the custom columns are going to work as refiners. I use a third party tool that enables me to fire queries and SharePoint Search and look at the results that come back to ensure the refiners and their values appear.
Search Centre
Customers I've met that have a go at SharePoint often don't add a Search Centre and maximise the use of search result pages. All their sites are still defaulting to the OWS Search, which if you have applied the time and effort to IA then you're not maximising the most of search.
If you don't have a search centre then create one.
We need to copy the results.aspx page in the search centre and call Company Document Results, for example. We need to edit the page and get our refiners on. Also, we want to filter the contents of the search so that only results are returned for the Document Centre.
The final piece is to configure our Document Centre to send searches to our Company Document Results page in the Search centre.
For those wanting to a more modern UI to their search then look no further than the PnP search available here https://microsoft-search.github.io/pnp-modern-search/
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 container (Document Set). No content could be added at the root of the library as all default content types had been removed.
Content would be automatically tagged using the Dept. column which would be inherited on documents based on the Document Set column.
Content added to the site would require users to select the content type and confirm they have set it by the required column Content Type Set?