What document library features should be used for department Intranet?

Question

I'm trying to design a new Intranet in an on-premise SharePoint 2013 Enterprise environment, but do not know enough about most features to be confident in decisions.

I have around 50 different Content Types defined for documents used throughout the company. A lot of the types inherit from parents, such as forms, manuals, operating procedures, etc. I am making a Publishing subsite for each department, and am now trying to come up with the best approach for the department document library.

After reading a bit and going through a few self-paced training videos, it seemed like the recommended approach was

1. Never use folders! Folders are bad!
2. Group everything into a single Document Library and organize using Views

I'm starting with one department for now and will go from there. My first attempt has been to create one single Document Library where I added all 50 Content Types, as well as some External Data columns. Creating views for the grouped content types was relatively simple, with a series of "or" filters checking the type. (i.e. content type = "absence form" or content type = "expense request" or content type = "work request" for a "Forms" view)

Unfortunately, this didn't provide easy document upload features like prepopulating certain bits of metadata based on the current view.

This led to me discovering the ability to set default column values for folders. It also introduced me to the Document Set content type. And now I'm mostly lost.

For this type of scenario, what is best?

1. Are folders actually fine afterall?
2. Should I be using Document Sets to group things, even though they're not necessarily related aside from content type?
3. Should I be creating multiple Document Libraries instead?

Thanks!

Answer 1

'People think in folders'. Although the familiarity of folders cannot be questioned, Document Sets provide a similar experience with far more capabilities. Read more about it here.

I had the same scenario with views versus multiple libraries. In the end we made a decision based on security/permissions and created multiple libraries (with views) for some sensitive document types.

Answer 2

I wound be very careful about mixing the Intranet (one to many communication) with "where we works". The main reason is that the departement structure is pretty volatile and the second reason is that this structure permissionswise does not support any cross org work. The most common approach is to have the Intranet as one Site Collection where everyone has read permission to just about all content, and specific editors for each departement subsite. Any project or similar work will be handled in other site collections and related to a departement using metadata, and surfaces in the departement sites using search. I have done a number of intranet projects and one finding is that multiple content types in a list/library is a very strange concept to the end user where one content type per list makes sense to them

Answer 3

I'm a huge fan of a flat library structure. Other than securing a group of documents (which can still be done with a Document Set), folders bring nothing to the table imo.

The way I do it is by:

1. Sit down with each department in the company to gather a list of Content Types, based on their current files in a file share.
2. Once I've got the list of Content Types, I explain the concept and need for tagging as this is what they would sort and filter their document library by. I don't add all columns to the default view as it gets too cluttered, but these can be used for refining within search.
3. Check with the department to see whether they have any document templates for each Content Type and edit where necessary (so clicking 'New Document -> Expense Form' loads the Word/Excel template).

With regards to document sets, I use these to 'bind' contents of a similar nature together. For example, in my current workplace we have a 'Property Library' which contains all the documentation for every property we manage. Each property may have anything from 5 to 500 documents. For this reason, I use a Document Set (tagged with metadata) to contain all of the documents related to that property.

Reading through your example for forms, I personally wouldn't use Document Sets, and would instead have a 'Document Type' column (managed metadata) with 'Manual', 'Procedure', etc. attached to each Content Type. That way you can just filter the list to view the appropriate documents.

On a side note: I'd take a look into Managed Metadata if you haven't done so already.

Answer 4

To answer your points individually:

1.) No, correct first time, avoid folders at all costs! They can become a developmental/administrative nightmare in the future.

2.) Document sets are generally reserved for groups of related documents, so I wouldn't recommend using these in your case. However, feel free to read Microsoft's own position on document sets and make your own mind: Here

3.) This is entirely dependent upon scale. Microsoft claim that a document library can hold 30 Million documents, however through personal experience, it seemed to struggle above 10 thousand, note that this was after amending the list view threshold through central admin. Thus we split in constituent document libraries. If you do decide to split into separate doc libraries, I would recommend splitting per Department, and then sub-department/team if necessary.

A couple of points to remember also;

• Default values can be applied to a content type, however there is no OOTB way to restrict users from changing these. Unless you apply these values via an event receiver or custom client-side code.
• Add a column for each piece of metadata you will need to filter on i.e. Team, Document Type, Department Manager et cetera. Do this upfront, as bulk editing in SharePoint is not as easy as one would hope.