Culling Number of Document Class

Question

Hi Forum, 
 For the experienced M-Files users --> I would like to know how you have managed to minimize the number of Document classes in M-Files. 
 I have been told that we should aim to have as few Doc. Classes as possible. 
 We have therefore relied heavily on the use of Lists of Values (LoV) to keep common Documents Types together. 
 For example: 
 > Reports is a class and we have a large LOV for the various report types. 
 > Drawings is another class, which will have a LoV for drawing types or categories of drawings. 
 Do others have any advice or methods that they have successfully employed and can recommend. 
 More importantly do others have lessons learnt --> things you tried that did not work? 
 I would appreciate any wisdom and input from your experiences.

Tom Humm · Accepted Answer

Hi Jo, 
 What a great question! This is always an important consideration when considering implementing a vault for the first time or for adding new document classes to an existing vault. Generally, the rule of thumb I use to determine whether a separate Document classes is required boils down to the following questions: 
 - Does this class require special structural or business considerations that make it unique to other classes? 
 - Are there specific metadata fields unique to the content? 
 - Does this content require permission constraints that need to be enforced that differ from other content? 
 - Is this content needing to follow a workflow which needs enforcement? 
 If you're answering yes to any of these, chances are you need to segment the content in question into it's own class. There are absolutely ways to achieve each of these without creating classes, but, these often cannot guarantee enforcement in all scenarios like utilizing a class typically can. This is definitely a balance though, since it's also important to always consider the end-user's experience. Having a significant number of document classes can often lead to confusion around what to utilize. I would always recommend using a minimum number of classes to achieve the desired end result but this will vary from vault to vault based on what is trying to be accomplished. If you find your vault is getting too complicated it may also be worth considering segmenting content at the vault level, this can focus the use cases and functions within each vault and further clarify what a specific department or business unit has to learn/use. User with access across multiple vaults can leverage cross vault search to find content across multiple vaults so users often don't really need to worry about which vault they're working in to find the content they need (provided they have access of course) 
 I hope this helps with your question, please let me know if you would like for any further elaboration! 
 Tom

ssential · Answer

Don't be like us! 
 Users will be quick to advocate for their specific and preferred terms for document classes. 
 Unfortunately, five years ago, this led us down an ugly road where we ended up with 120 document classes - AVOID this at all cost - why? because your users will understandably feel overwhelmed, and then additionally when they need to search, they won't have a clue of where to begin. 
 The last two years we've been reversing the damage to create a GLOBAL taxonomy of classes. Instead of having the term that "Team A" uses, and the term that "Team B" uses, we endeavor to get them to agree on a term that captures the document type, so it's intuitive and universal, but not too broad and not too specific. We also use metadata card configuration rules to add in a definition of the Class' intended usage so it guides the user. 
 This is no small feat if your organization is incredibly complex. 
 Avoid the bad ones: Miscellaneous, Summary, Content, General = all of these will create a massive headache for applying retention and streamlined workflows. 
 Today, we've struggled and worked WITH users to reduce the options to 60 classes, with more on the chopping block later this year. 
 As an example, we have a Class "Agreement/Contract"(we couldn't get them to agree, so we do provide either), other examples are "Email/Letter" "Data/Tracking" and "Itinerary/Schedule" - we do provide an optional Value list for the "Types" see example below. 
 so we have "Report Type" "Agreement/Contract Type " etc. 
 This is the "Big Bucket" approach, but not too big of a bucket. 
 However, careful with creating too many values under these "Types" - I recommend ensuring the meet a certain threshold. If only one team uses a "Report Type", and they'll only have a dozen a year, it's not worth creating that option for users. 
 Remember: too many options creates too much NOISE, and too much noise means users won't feel confident in searching and creating Views for fear they won't have all the documents they need due to this 
 
 Happy to chat, feel free to message me directly. This is a path I want to help other Admins avoid!

Culling Number of Document Class

Top Replies