Building a successful document management system on SharePoint is not a hard task, but it certainly demands a precious amount of knowledge and effort. Trust me, the process can take some time, Documents in SharePoint is going to be worth it in the future of your business when the complexity and the amount of documents can be overwhelming. In the hopes of making this process more accessible to everyone I am sharing our best practices on SharePoint Document Management in a series of posts.

On part 1 of this series I’ve presented a SharePoint document management plan model and discussed the first two points: how important it is to analyze the existing documents in your environment and how to create a consistent Content type structure.

On this post I am covering two more point in which I am going to discuss what type of containers you should choose for storing documents in SharePoint 2010 or 2013 and demonstrate how to do it.

Plan for Documents in SharePoint management

1. Analyze existing documents. Determine document types, properties;
2. Create a flexible and easily extendable Content Type structure;
3. Choose where and how to store documents in SharePoint;
4. Create fields, sites, libraries and lists. Add Content Types;
5. Plan for permissions;
6. Define and automate SharePoint document naming;
7. Unify document templates location;
8. Distribute content to smaller files;
9. SharePoint Document Automation;
10. Implement Workflows;
11. Optimize views and libraries;
12. Findability and Search;
13. Backup & Recovery;
14. Plan retention and SharePoint Content database growth;
15. Have a Migration plan.

Step 3. Choose where and how to store documents in SharePoint

When we talk about WHERE to store documents in SharePoint we are always faced with a choice to make: Should I use a SharePoint List or Library?

As you know, in SharePoint you may choose to store your documents in a SharePoint lists, as items’ attachments, or in document libraries, as items. Well, the choice is not as easy as you may think and depends on some variables like your document types, business processes, security requirements and the functionality you are trying to achieve. Let go throw both cases:

SharePoint List – Storing documents as items’ attachments

Advantages:

• Multiple documents can be supported by one single item since every item serves as a container for the documents attached to it. It’s a good option (especially if you use SharePoint foundation, where My Sites or Document Sets could not be utilized) to store incoming documents like: email communication with business letters, meeting agendas or protocols attached; contracts with additional specifications or appendixes; employees list with related individual documentation; storing the same documents but on different file types (.docx and .pdf for instance) or documents that do not require to be modified;
• Item-level permissions and fine granted access could be engaged more easily comparing to document libraries, as there are additional settings for lists like:

SharePoint Library – Storing documents as items

Advantages:

• Opening of documents is faster and more convenient;
• Supports the simultaneous editing of a document or co-authoring;
• Supports the Open with Windows Explorer function and simplifies document management, copying and deleting process;
• Document generation and mail merging process is simplified by the usage of file’s metadata and auto-filling. Works well for generating customizable contracts, invoices, business proposals, presentations and reports with SharePoint, specially using ourdocument automation solution JungleDocs;

I think it’s clear that the option of using SharePoint libraries to store documents brings more benefits than disadvantages, and opens more possibilities of usage. That’s why we are trying to avoid using SharePoint lists when designing document management systems in SharePoint and that’s why in this post and subsequent series posts I will be focusing on storing documents in libraries. We like better to see documents as a central point in the system, having content types, metadata and templates as support factors for very good document automation and migration possibilities.

Once you decided on where to store your documents, you can move on to HOW you’re going to manage them, and this depends on variables like the expected items amount, environment requirements, and permission considerations. Lets analyze some storage methods available in SharePoint:

Plain Views

This is a default, widely spread and very good option for libraries containing less than 5000 items and not using fine granted permissions. If you think your library is not going to reach that amount, or it will only happen in a few years, just go ahead with Views as this is the simplest and the most easily manageable way. The only exception is a requirement for grouping or having containers for documents;

Folders

Document Sets

They are hybrid folders with some features on top. The main benefit of document sets is the ability to propagate metadata to inside documents. This is especially useful to bulk upload new documents like storing contracts with appendixes or employee information. We can set metadata of a single uploaded document, but when doing it in bulk, I doubt anyone comes back to change properties of every single file. Using document sets you don’t have to do that. Shared metadata will be updated by a timer job. Depending on the amount of information involved the timer job might take some time until all metadata is correctly set for the new documents. But it will work. Don’t worry.

Going with one single choice as a solution to manage documents in your SharePoint will not work. Ideally, a little of everything should be used to maximize the efficiency. So whichever combination you choose, storing documents in one place will let you utilize SharePoint functionality and believe me, it is much more efficient that whatever we can come up with ourselves. Views, filters and search are all powerful tools that will make your life much easier.

The last point on this part I want to talk about is not about how you store your documents, but how you can easily access or filter them. It should complement all storage methods described above:

Managed metadata

Consists of centrally managed terms that can be used as item attributes. Level of management can differ, from strictly defined set of terms to open sets that allow user contributions. Central management ensures consistency across your company and eases search, but everyone in your company must be aware of the terms or “tags” to use them properly. It might require a bit of training.

Step 4. Create fields, sites, libraries and lists. Add Content Types

On this point I am going to discuss the logical organization of libraries starting from considering how big your library is going to be. Of course I don’t mean that all documents should be stored in only one single library like Shared Documents, God no. Document management in SharePoint is usually performed grouping together documents of same or similar content types and using a collection of sites and document libraries. Sometimes, for very big environments, documents should be split into several site collections or even web applications with separate content databases.

Before you create storage places for all types of documents in your SharePoint, analyze your current situation and draft a structure for the information. Calculate how many sites and subsites you will need, how many document libraries there will be and how they all will be associated. There should be as few storage locations or libraries for documents as possible.

Hot tip: You should store the mostly reused data in the top site of your document management hierarchy. Main reason for this – you can only create lookups that come from the parent site. Site columns can only be inherited down, so lookups will only go up. It is only possible to bypass it by directly modifying the lookup field properties.

Two techniques

We are using two techniques for organizing data structure:

First is a standard one, when you organize documents per document type: types of documents like Proposals, Contracts, NDA’s, Business letters, etc. and documents related to different organizations, projects, employees and so on – putting everything in separate libraries. Basically we classify these documents using lookups from parent sites (Companies, employees, project n., etc.). Using such architecting method, you will have all documents of the same type in one library – for instance all proposals for multiple customers will be in the same library.

Another technique is to organize content per entity, like Customer, Project or employee. By using this technique, you are organizing you structure as Site per Customer or Site per Project, etc. Each site will have required libraries, lists, calendars or pages within it.

A site per entity method can be very useful once you define site templates for new entities. We also use this technique for managing projects at EnovaPoint. However this architecture can be a real pain in the case if you require to change an existing structure. You should be very careful when implementing such structures for large amount of entities-sites. In this case you definitely need to have a plan or tools if you will be required to change the structure. Complications may appear if you will require to generate reports from multiple locations or to watch particular library for changes or expiration.

That is it for this time. Feel free to leave any comments and make sure to check the 3rd part of this SharePoint Document Management series where I share how to plan your permissions without compromising your document management and automation system in SharePoint.