The M-Files Community will be updated on Tuesday, April 2, 2024 at 10:00 AM EST / 2:00 PM GMT and the update is expected to last for several hours. The site will be unavailable during this time.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Culling Number of Document Class

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.

  • 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

  • I 100% agree with everything that says, but I'd like to add one thing from the user perspective.

    As Tom said: I recommend that you go with the minimum number of classes you can.  The absolute worst thing in the world is for a user to be looking at the list of classes and saying "does this belong in class A or class B?".  The likelihood is that some people will choose A and some B, and you then have a real mess sorting it out.

    i.e. each class should be completely distinct from the others.

    If there's any possibility that creation of a new class might create confusion then it's likely that you should instead consider an additional value list (e.g. "Drawing type") to differentiate it.  This can be used to then perhaps add two values (e.g. "this drawing contains electrical and gas elements, so I can choose both 'Electrical drawing' and 'Gas drawing' types, but it's still a 'Drawing' class").

  • Thanks and great input from you both. Would you have any examples of special structural or business considerations.  Only as an example - Forms are unique in that we have different metadata and workflows associated with each form, but you can imagine most organizations have tens of forms - especially when dealing with different geographical locations, languages and laws. In this instance I had considered having one Document class called "forms and applications", a drop down menu for the various types such as:

    • investment application,
    • travel application
    • credit card form
    • Change request form etc

    and then I was hoping to use the metadata card configuration to drive what property fields should and should not be visible. Am I heading down the right path here? or is there a better solution?

    Gents, thanks again - really appreciate your knowledge here!

  • I personally think what you've suggested sounds good.

    One thing I would add is to say that I also personally do not like catch-all class names.  I've seen a number of vaults with a class of "Correspondence", for example.  It's such a broad term that people will throw almost any email that they send into that class, regardless of whether it's actually an Order or Termination Letter or...  I know that there is sometimes a need for such structures, but I personally think that they add confusion to the user.

    As such, a class of "forms and applications" may be considered too broad.  Is this a form that a user has submitted, or the template that they should send out to people?

    It's tough, and there's no correct answer.

    But I'm a mere code-monkey;  probably has more real-world experience, so I bow to his knowledge in this area.

  • This makes sense to me.  Only concern i might raise pertains to feature parity between the Desktop and Web Clients, some items are still displayed differently in web as compared to Desktop, so if you're users are leveraging web (or mobile) this might not work. 

  • 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!

  • Great to hear real-world feedback, thank you !

    As a slight "aside" to this conversation, one tactic I have used in small pilot deployments is to have a very small set of classes and then have a "No suitable class" class.  This way your pilot users can still use M-Files even if they find a class you've missed.  You can use notifications, reporting, or even a view, for the project team to then look at what issues people had and to either educate them ("why didn't you use this class?") or to decide to increase the number of classes.

    But never do this in production; only in limited-duration pilots where you can be on top of what's going on!

  • Thanks for the screenshots - very helpful !