The structuring of SharePoint is a very important part of information governance, and can determine whether or not your users are able to effectively make use of SharePoint as a tool for organizing and capturing important information. Without a solid plan on how you are going to structure your environment, SharePoint can quickly grow out of control as new team sites, libraries, and content types are created on the fly by basic users. SharePoint is a tool that is meant to allow you to organize and control your data, and without an effective structure, this will not be possible.While Collabware CLM can be configured in many different ways to fit any kind of SharePoint configuration, from the highly organized to the intensely complex, a well-structured SharePoint can be leveraged by Collabware CLM’s Content Rules Engine, giving your organization much more control over what records are captured. In the end, it is much better to start with a SharePoint environment that has strong governance before you begin configuring the records management features. Of course, this is not always possible, especially for already established SharePoint environments. However, some of the following information may still be useful to those wanting to achieve better control over their SharePoint data.
Three Levels of Structure
There are three distinct levels of structuring that can be done in SharePoint, which can be described simply as Site Structure, Content Type Structure, and Metadata Structure. Each level of structure relies on the others, but each can be understood as distinct levels. Along with this, there is a hierarchy to these levels of structure, with each smaller level fitting in the larger. It looks like this:
Site Structure
-> Content Type Structure
-> Metadata Structure
Along with this, two of the levels of structure can be broken down further. Site Structure can be separated into Team Sites and Libraries, which rely on each other, but can remain distinct. Content Type Structure can also be broken down into Document Set Content Types, and Document Content Types. A Document Set is like a folder, but can be managed as a single item and is capable of metadata sharing (as a side note, try to avoid folders within your SharePoint libraries at all costs; they are ineffective organizational tools). Our final level of structures can look like this:
Team Sites
-> Libraries
-> Document Sets
-> Documents
-> Metadata
Try to imagine these five levels as your organization tools, each with its own strengths. Using each of these different levels, you should be able to break down any company into more palatable chunks. Let’s talk about each level and give some examples of how each level can be used effectively.
Team Sites
SharePoint’s Team Site is the top level that any given user should be exposed to. Occasionally you will run into situations where a group of users may need to work within two different team sites, but this should be avoided if possible. The reason for this is that your team site is your first, and sometimes your only, level of permission grouping. That is what the primary purpose of the Team Site is a chance to start filtering your users into logical groups.
The simplest way of grouping your users is by department. Almost all organizations have some kind of department grouping, and it is easy to identify members of each department. The other benefit of this is that the permission grouping makes sense; normally people in operations do not have access to the data in finance or human resources.
For this blog, let’s use as our example the Legal Team Site.
Libraries
Our next level of structure is the Library level, which is contained within each Team Site. Here is where you need to research a bit, usually by interviewing members of each Team Site. One of the most effective ways of constructing Libraries is to build them around an activity that the department carries out. This activity can be as simple or complex as needed. For example, office regulations are fairly simple. They draft some kind of document, it gets approved, they disseminate it to the office; however, the document itself is simply created and kept in that single library. Nothing special is needed here. A more complex activity that Legal would carry out could be Agreements. Agreements require many different documents to be created during the course of drafting, discussing, and finalizing an agreement. There are many stages to creating an agreement between two organizations.
Regardless of how complex or simple your activity is, it is almost always a good idea to build your libraries around those activities. Your users will always know what kind of activity they are carrying out, and having a single place to put all their data related to this activity will help them.
Our sample Library will be the Agreements Library in the Legal Team Site.
Document Set Content Types
Document Sets are not always necessary for SharePoint structuring. However, they can be extremely useful when they are called for. A Document Set should be used when you want to keep one subject separate from other subjects. Another way to describe a Document Set is to think of it as a Case File. Case Files almost always refer to a person, place, or thing: an Employee File for John Smith, a Building File for an office, an Agreement File for XYZ Corp. A Document Set collects together all the documents for a single subject, keeping them separate from all other files.
The Document Set level is an interesting level to create, because you are creating a Content Type that will be used in the future for a number of different subjects. It requires knowledge about the volume of data created for each activity. If an activity only generates a few documents a month, there is really no reason to start capturing them under Document Sets.
For this blog, we will use a Partner Document Set, to capture all the information about a single partner.
Document Content Types
Unlike Document Sets, Document Content Types should be created as much as possible. This is a very important piece of any SharePoint system. Content Types are how you define one piece of content from another. Without a Content Type, it can be difficult to differentiate between a rather benign piece of content, like a Memo, and a very important piece of content, like a Contract. Content Types also help you control where certain pieces of content are created. Each Content Type must be assigned to a Library, providing control over whether or not someone should be creating, for example, a Human Resources Complaint document in the Communications Library.
Keeping in mind that we are several levels down into the structure of SharePoint, it should be recognized that we have already done much of our separating, by using both Team Sites to capture large work groups, and Libraries to capture smaller work groups dedicated to specific activities. Down at the Content Type level, it is now possible to start supporting those activities by creating pre-set document types that are created by those activities. Each Content Type should have its own set of Metadata Columns targeted to support the document that it represents. Try not to add additional columns that are unnecessary or do not support that document; it can potentially frustrate users and make buy-in more difficult.
We are going to choose the Agreement Content Type here, as it fits quite nicely into our library.
Metadata Columns
The bottom level in any SharePoint system is the metadata column. Metadata is integral to any information management system. Without good metadata, many important features cannot be utilized to their full extent. Computers have revolutionized the way people search and organize data, but without proper metadata, this becomes impossible.
Our example Metadata Column will be Agreement Expiration Date.
SharePoint search is a powerful tool that can crawl not only documents, but also their metadata, capturing this information to be used in future searches. The way people search for information can be random and unpredictable; not everyone remembers the name of a document, or even knew the name in the first place. They rely on other pieces of information to find the information they need, whether that be the original author, the subject, the date it was written, a shared file number, the list goes on. The only way they will ever be able to find what they are looking for is if this information is captured properly.
Moving on to the organization of content, metadata also plays a very important role. Gone are the days of folders! We no longer require a huge number of folders to capture information. Think back to the old days of File Shares with endless Folders; to find a single piece of content, you had to navigate through several layers of Folders. It would certainly be organized by year, a very common practice, and then perhaps by subject, and then even by author, and even then you would have to deal with dozens of oddly named documents without any additional information! This is completely unnecessary now. SharePoint provides you the ability to sort and filter by any metadata column in a library. If you are looking for a specific user, simply filter by their name. If you want it within a date range, sort by the modified date and navigate to the year you are looking for. Anything that can be captured as metadata can be used to organize documents within a Library.
Effective Structuring of SharePoint
There are two key points to take away from this blog post. First of all, SharePoint Structure is very important. It gives the system much more flexibility, context, and power. It enables users to create spaces where they do collaborative work. The second point is that there are many different levels to SharePoint Structure, and it is important to recongize that each level has its own purpose and best use.
With this brief outline in mind, you should be able to tackle any kind of working group and create something that fits their needs.
