A common question we hear from organizations when they first look to implement Collabware CLM is related to the capture of documents into the File Plan. One way or another, the organization needs to make a decision on how their users are going to classify their content (read about the importance of record classification here). It is very rare that an organization will want to expose their File Plan to their users, requiring them to understand and be capable of choosing the correct Record Classification for every piece of content. Some organizations are lucky enough to be in a position that this is possible, but more often than not, basic users are simply not familiar enough with their File Plan or basic records management to be able to navigate these requirements. So the problem shifts to determining the best approach when utilizing Collabware CLM’s Content Rules Engine to align the File Plan with another set of matching terms. Organizations mostly tend to gravitate towards two different approaches, which I will call “Content Types” and “Document Types”, and there is also a hybrid approach.
Content Types Approach
The Content Types Approach is probably the most common approach, especially for organizations that already have SharePoint set up, and have already been leveraging the SharePoint Content Type for other reasons. Content Types are valuable tools for separating content into distinct units, allowing organizations to create focussed metadata sets to ensure they get the most out of SharePoint’s search and sorting features. There are even some organizations' File Plans that have been built around SharePoint Content Types.
This approach can be configured with the use of only one Content Rule in SharePoint, making it very simple to set up. While the other methods may be more complex in their initial setup, the important point to consider here is not what is easiest to set up, but what is best for your organization.
-
There are several benefits to the Content Types Approach, mostly aimed at your SharePoint users. Building a File Plan to map directly to Content Types allows users to ignore the records classification field entirely (and in fact, many organizations choose to hide this field). All users must understand is that they must choose the correct Content Type when uploading a document. Normally, Content Types are so straightforward and easy to understand that users can generally select the correct one, cutting down on the amount of improperly classified records. In fact, SharePoint Document Libraries can be built around a single Content Type, taking even this out of the hands of regular users.
However, of course, there are also drawbacks to this approach. These drawbacks are mainly on the infrastructure team, although some of them affect regular users as well. The first and most obvious one is the sheer number of Content Types that need to be managed. Not only does each unique Content Type need to be configured by hand, including all relevant metadata being added, the infrastructure team must also add each Content Type to every Document Library that requires it. This can be mitigated partially by using a parent Content Type that has shared metadata, but if your organization requires unique metadata, this must be configured manually. If your organization chooses to only have one Content Type per library, you must create many different libraries, potentially confusing your users with all the different places they must upload content. On the other side of the issue, if you choose to put multiple Content Types on a single library, the chances of users not realizing they have defaulted to the wrong Content Type are greater.
The final issue with this approach is that it is not easily modified. Any little change to the File Plan or Content Types will require a lot of extra work to reconfigure, publish, and update working spaces and content. It’s not as fluid as the other approaches. In some cases, this may work fine, as the organization may be already thoroughly entrenched in SharePoint and have enjoyed stability for a long time.
Document Type Approach
The Document Type Approach comes at the issue from an entirely different angle. Rather than trying to separate everything into different Content Types, a single Content Type is created and shared by all working groups within an organization. In order to match to a record category, a Document Type is selected by the user that corresponds to what they are creating. The Document Type is chosen from a managed metadata term set that has been added to the default Content Type.
This approach is achieved in Collabware CLM by using the same technique as outlined in the previous approach, although mapping it to a different metadata column (in this case, the Metadata Column "Document Type", rather than the Column "Content Type"). However, in some cases, organizations may want to give their users more than one option for each Record Category, as in many cases, more than one Document Type corresponds to a single Category. In this case, there are a few different ways of setting this up, depending on the volume of document types per Category. The first method is to simply add more file plan metadata fields to use with Content Rules, as demonstrated below. This method is best if you have many Record Categories, and only two or three different document types per category.
The second method is best for those organizations who have many different Document Types that match to a single record category, and creating a new Content Rule for each one is too onerous. In this case, a single Content Rule is created that makes use of the “Equals or is Child Of” operator in a Content Rule Condition. This allows you to bundle together several terms under a single heading, and add the Content Rule directly to the Record Category.
-
-
The benefit of this approach, regardless of how you set up the Content Rule, is that it allows users to work with terms that they are fully familiar with, and it provides them with a variety of choices when working within a library. This is very important when trying to garner buy-in from your users. Normally, it is the users themselves that come up with these lists of Document Types, so it allows them to feel comfortable with the environment. Updating a managed metadata term set is a simple matter that only requires adding the term, making it easy to extend and keep up-to-date.
However, there are a few drawbacks to this approach as well. When using a shared document across the entire organization, it limits the amount of specific metadata you can add to the document. Much of the metadata that could be added will simply be too specific for the Content Type and encourage users to ignore metadata entry, which is something you never want to do. The metadata columns presented to a user should always be relevant to their business needs. Along with this issue is the fact that the Document Types term set will be unwieldy for a user to sift through in order to look for the Document Type that they are looking for. Some users will be able to navigate the hierarchy quickly, but others will struggle.
Hybrid Approach
In the end, both approaches have benefits and drawbacks. However, it is possible to set up a system that uses the benefits from both, while partially mitigating the flaws present in both. This is a hybrid setup that attempts to utilize both Content Types and Documents Types to facilitate record capture.
The basic concept is that rather than using a single Content Type and a huge Document Type list, you split up the Content Types into their respective departments. Since most SharePoint implementations are divided along department lines, it makes sense to mirror this in the Content Types. Rather than having a huge list of all possible Document Types, this enables you to craft a Content Type per department, presenting users with a narrowed list of Document Types to choose from as well as a set of relevant metadata columns to populate with important information.
Setting this up in Collabware CLM is not hard at all, because it can be set up using the techniques we already reviewed in the Document Type Approach. Either of the two presented Content Rule styles will work here, so it depends once again on the volume of Document Types you have for each Record Category.
There are several strong benefits of to the Hybrid Approach. First of all, you mitigate the initial problem of presenting your users with an excessive list of Document Types to choose from, avoiding potential choice paralysis. Leveraging the same Document Types list as used in the previous approach, you simply narrow the Managed Metadata scope when creating each department’s Content Type.
Second of all, as mentioned above, Content Types can be designed to fit the individual needs of each department, without getting into the detail and complexity that the Content Type per Record Category approach requires. Along with this is the fact that it is much simpler to implement; rather than having to add several Content Types to each library (or create an individual library for each Content Type), you only need to add a single one, dependant on which department the library belongs to.
What is best for your organization?
All of this discussion is entirely dependent on the needs of your organization, which will never be the same as the needs of another organization. It is up to you to review the relevant facets of your organization in order to accurately select the best solution. A few suggested areas to review would be the following:
These are just some of the important factors to consider. There are others as well, some that may be specific to only your organization. The main take-away from this blog should be the fact that there are lots of options for configuring this aspect of your records management solution, and every option is equally viable depending on your initial conditions. While the Hybrid approach does have fewer drawbacks, that does not necessarily make it the superior solution for your organization. Spend the time to review all relevant information in order to come to the right conclusion, and if you already have a solution in place, it never hurts to look at it again with the amazing perspective of hindsight.
Questions about Collabware CLM? Contact us or download a free brochure about this solution:
