Moving forward with our document management series, we come to the topic of document content itself. I will talk about how you can manage document content efficiently and ensure a tidy environment. First thought might be that it is not important how we manage the content of documents, as long as the documents themselves are easy to find. However, the way you choose to manage document content, directly affects the way your SharePoint as a document management system is built, and may even limit or expand the possibilities of document management.

Plan for SharePoint document 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 7: Unify document templates location

First thing to do here, would be to take a look at the plan of your document management system (that you hopefully prepared beforehand) and take note of all the different documents that you either store or generate in your SharePoint sites. This will let you decide what kind of templates to use.

As a general suggestion, templates should only contain the most common content and formatting in them. This means, that no actual information regarding customers or services should be in the template.

For us, at EnovaPoint, an ideal template is just a layout for new documents that shows where all of the data, like customer details, product descriptions or price lists need to be inserted. How can we do that? We distribute all content into smaller files and assemble new documents merging those smaller ones together. I will comment more on this in the next step.

Templates should be stored in a single location. If you use content types to create documents in SharePoint, you can store all templates in a single SharePoint library and simply assign a template to the required content type for use in the required library. This has multiple benefits over the default content type template or choosing to upload a new one:

• You can ensure that only the latest version of the template is being used;
• You can easily search and migrate templates; you can even do a simple drag and drop in Explorer view to move them all;
• You can manage who can edit templates by managing permissions on a single location and in turn you can easily monitor who works with the templates.

Of course, in some cases having a single library for your SharePoint farm will not work. Our suggestion in this case stays generally the same; you should create and manage a separate location for all of the “system” documents for your site collection at least. You should have a separate site for templates and other bits of your SharePoint document management system securely stored there.

Step 8: Distribute content to smaller files

Templates and content distribution are two closely related topics, because at some point, distributed content will have to be inserted into the templates, or it all makes no sense. By saying content distribution, I mean that all possible reusable content should have its own separate storage location.

Let’s consider the following example:

We need to create proposals to our customers, and depending on their needs and the products we are proposing, the final document looks differently. Now there are multiple ways we can go about this, and let’s analyze two opposite approaches.

Method number 1

We can try to create all possible variations of the final proposal, so that once we need it, we just take a ready one, fill in customer information and send it.

Other big concern at this point is scalability: if a new product gets introduced, many different proposal types might need to be created simultaneously, thus increasing amount of the “Templates” exponentially. And that can never be good. At some point no one will know which of them, is the correct document.

Method number 2

As opposed to having ready documents for every situation, we suggest building them on the fly. I already talked briefly about the template content. Namely, templates should contain exclusively the content that is mutual for every possible variation of the final document. Let’s say my proposal consists of these chapters: Title page containing company and customer information, Introduction about whatever is being proposed, Actual Details about the proposal, and a Conlusion” like client testimonials or price lists, depending on the situation.

“Depending” is the key word here – if we look closely, every part of the proposal varies. What is the mutual content at this point? In my case it is just the title page. And that is exactly what my template looks like – a title page with header and footer, some placeholders for customer information and proposal details. Everything else is stored in separate files in other library.

Now that has multiple benefits over method one:

• It greatly reduces number of documents needed to take care of;
• Every piece of information is only found in single location and that means only a single update is needed to keep a topic fresh;
• Storage can be strictly defined and access can be limited for required groups or people.

So how does it actually work?

As you can guess, I am more enthusiastic to use second method. In the real word, however, joint solution must be found, making the best of all available knowledge. At this point everything would look something like this:

• There is a separate site for all system files, templates and distributed content that we callSmall Parts; No actual documents are being created here;
• In that site there is a library for templates; Depending on how many templates you actually have, multiple libraries could be used if you need to separate different types of templates;
• For small parts, there is a single library with multiple folders for all available types of small parts; We have different templates for different products, but all of the actual information is still stored in small parts;
• Outside of system site there are multiple libraries where generated documents are stored.

As I mentioned, we use JungleDocs to generate documents, so multiple templates makes creation process simpler at this point, because amount of the templates still stays in single digits. Our templates contain placeholders for customer information and small parts. To create a document we simply need to run JungleDocs, select what template we need to use and what small parts to include. Everything else is done automatically so it is super simple.

You can check it out how this process works at this JungleDocs document assembly video tutorial.

Even without JungleDocs, this type of content distribution makes sense. As we see, there are multiple benefits and the only downside is that a little bit more copy-pasting is required to get the same result.

Thank you for keeping up with this series, good luck with your documents and let me know what you think about it in the comments!