2

Newbie to SharePoint, I have been tasked with redesigning a work site used for collating Business Process and Work Instruction documents.

I would like to create various categories for each of our work streams and then have the Process and Work Instructions linked to the correct category.

I'm struggling with the fact that some work instructions could fall under multiple categories. I obviously don't want to duplicate the the documents in each category.

I'm thinking that I need to tag a documents with Category A and Category B and then when the user clicks through to either of the Categories they would see the document.

I'm not sure how to achieve this though.

Is anyone able to point me in the right direction?

Cheers

1 Answer 1

2

In situations where a document should be part of more than one category, it's recommended to trust in metadata and views. The whole document management architecture may vary depending on at least the following

  1. the metadata hierarchy the documents are part of,
  2. how trained your users are (i.e. in using the SharePoint's functionalities),
  3. the way the documents are created and uploaded, and
  4. the overall amount of documents to be added.

Explaining each of the above mentioned a bit more:

  1. The document hierarchy can be shallow of deep, and one should always aim for a shallow one. An example hierarchy could be the following:

    Company Documents

    Marketing

    Internal Marketing

    External Marketing

    HR

    Salary

    Company Introduction

    Production

    Logistics

    R&D

    Testing

    IT

  2. Users' skill level with SharePoint tends to vary, but if the users have received a basic training for the document management functionalities, such as uploading a document, adding metadata and moving a document, you should be able to get far. Ways to control this are many, such as hiding functionalities, creating clear instructions, limiting the users who are able to handle documents, etc.

    The risk with a poor user training is that the document management can easily collapse when users would handle documents as they often are used to, which sadly means copy+pasting documents in an extremely deep folder hierarchy using Windows Explorer. This would quickly result in poor searchability, usability and an overall lack of motivation towards the process.

  3. Documents can be created automatically with default time intervals, every now and then by hand, or anything between these two, or a mix of many.

    An automatically created and uploaded document can easily not become tagged with metadata, but many processes may be dependent on automation. I'll explain a bit further how I'd handle an environment with fully automatized document creation.

    Manually created documents don't suffer from this, as the metadata can be requested from the users. The trade-off is that there shouldn't be thousands of documents when purely manual processes are used.

  4. Lastly, as touched above, the amount of documents matters. Pre-SharePoint document processing can be driven by automation or not, but uploading thousands of documents becomes quickly something that nobody should do by hand nowadays. Additionally, if the numbers are in thousands, SharePoint's built-in limitations need to be considered.

By finding the answers to the above questions, the hierarchy & process that should be implemented to the SharePoint can be determined. By now, without knowing your case, I'd give an example implementation:

I'd start off with a single Document Library which should be the common name for all of the documents to be added. Instead of using Folders, I'd prefer to use Document Sets always when possible (read more: Introduction to Document Sets). Document Sets also limit the hierarchy to become two-level, but that's great. You don't want n-level hierarchy. Folders died already. Ok.

Each Document Set allows the use of the following:

Specify any shared metadata that you want synchronized to all documents in a set.

This means, that if a document is uploaded to a Document Set "Internal Marketing", it can receive the metadata "Internal" and "Marketing" automatically.

After the use of metadata, views can be built to your document library. Views are a great way to show only documents, when 1. the user has access to the document, and 2. when the document is part of the scope of the view, defined by the metadata. The scope is defined by the filter-settings of the view, where you can specify to show only documents which have a metadata e.g. "Company Function" "Equals" "Marketing".

As mentioned, this is an often applicable approach, which can be expanded. In a nutshell:

  • If you feel like you are going to need many document libraries to have several "parent-structures" for your Document Sets, then the best searchability is often reached with the use of SharePoint's REST API, or by a well-tuned SharePoint's search.
  • If there are complex metadata that should be added, e.g. to which country the document is mapped to, then you need to consider manually added metadata. You can still automatize the metadata addition when it meets your hierarchy though!
  • If your users will become unsure where to exactly put their document, start to use SharePoint's Drop Off Library and the functionalities around it (read more: Create Content Organizer rules to route documents).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.