Options
  • Replies 7 replies
  • Subscribers 13 subscribers
  • Views 255 views
  • Users 0 members are here
Related

Class - Doc Type: a design brainstorm

jmt@stricklandsolutions.com

A topic that has fascinated me for years has been to find the most elegant design for a 2 level document classification system. Elegant as in: easy implementation/maintenance and user friendly.

 

With such a 2 level classification paradigm, Class would represent "what the document is applicable to", and Doc Type would be "the actual type of document". The need for a 2 level classification is a very common design to an M-Files vault in order to control the number of classes to maintain.

 

The requirements

  • Limited number of document Class, and a Doc Type lookup property (on either a Value List or Object Type)
  • Doc Type lookup properties ought to be filtered by the Class
  • A Doc Type should be applicable to multiple Classes
  • Nice to have: AI should be able to "auto-classify"

 

Example

Class: Sale Related Document

Doc Types: Proposal, Agreement, Notes

 

Class: Project Document

Doc Types: Plan, Deliverable, Notes

 

Design Options

 

Option 1 - Open, unfiltered Document Type list

  • With this design, a Document Type value list is created and is unlinked to class. It probably doesn't respect the requirements 100%, but is one of the simplest design. Select a Class, the select a Doc Type.
    • Pros: Simplicity
    • Cons: Lack of control - A user could select a combination of Class an Doc Type that shouldn't exist, like Project Document and Proposal in the example above.

 

Option 2 - One Doc Type lookup property per Class

  • One could make X different lookup properties on document types each applicable to one class.
    • Pros: A clear linkage of doc type values to classes.
    • Cons: Lots of value lists and properties to maintain. Search filters can be cumbersome. Might not be easy to get AI to make the right recommendations.

 

Option 2.b

  • Document Type OT with "Related Class" property to filter which class they apply to
  • X different properties lookups on the Document Types objects, filtered on the Related Class

 

Option 3 - Filtered Doc Type list with duplicates

  • With this design, common Document Types are duplicated per Class as needed. For instance, "Notes" related to Sales Document class would have an ID of 2, and "Notes" related to Project Document class would be another Document Types having an ID of 3.
    • Pros: Can be done with Value List, not need for OT
    • Cons: Duplicate values might make the end user search awkward. "Which one is the actual value I need to use in my filter?"

 

Option 4 - Filtered Doc Type list no duplicates

  • With this design, Document Type is an object type, using a "Related Doc Class" property to filter which class they apply to. In turn, Doc Type LU property on a document would be filtered by the "Related Class" which is set on the document as a clone to the document class.
    • Pros: Works well responding to all design requirements
    • Cons: Complex design due to 2 factors:
      • The Related Class property on the Doc Type objects cannot be set through the UI, only API or MFImporter
      • The filter of Doc Type LU property can only be done through a Related Class property cloning the Class value. For this cloning to happen as the user creates a new document (or reclassifies an existing one) it needs to be done through static SetValue metadata card rules… one per class.

 

Conclusion

Neither design is ideal! Whether the user experience is compromised, or the Complexity is a showstopper, I have yet to find the perfect design. Would love to hear other people's thoughts... Share your thoughts, share your experiences, share your creative designs!!

Parents

  • For what it's worth, Industry Solutions Builder uses option 3 (Doc Type is a sub-list of Class and filtered by Class selection). Many of the classes have duplicate "Other" document type underneath them, for instance. For a lengthier description of the Client Information Management solutions built with ISB, you can watch this video. Partner Portal also has metadata structure documentation for these solutions.

    Regarding your example above, I think using "Sale Related Document" as a class should be reconsidered since it describes a process and not the document itself. You could use "Sale Related Documents" as a class group instead and have Proposal, Agreement and Notes as classes underneath it. One class can exist in multiple class groups, so you can add for instance Notes to several groups. Under Doc Types you could then have further classification, for instance class Agreement could have Doc Types Sales Agreement, Subcontracting Agreement and Non-Disclosure Agreement.

    It's an interesting topic, so happy to hear about other approaches and experiences as well!

Reply

  • For what it's worth, Industry Solutions Builder uses option 3 (Doc Type is a sub-list of Class and filtered by Class selection). Many of the classes have duplicate "Other" document type underneath them, for instance. For a lengthier description of the Client Information Management solutions built with ISB, you can watch this video. Partner Portal also has metadata structure documentation for these solutions.

    Regarding your example above, I think using "Sale Related Document" as a class should be reconsidered since it describes a process and not the document itself. You could use "Sale Related Documents" as a class group instead and have Proposal, Agreement and Notes as classes underneath it. One class can exist in multiple class groups, so you can add for instance Notes to several groups. Under Doc Types you could then have further classification, for instance class Agreement could have Doc Types Sales Agreement, Subcontracting Agreement and Non-Disclosure Agreement.

    It's an interesting topic, so happy to hear about other approaches and experiences as well!

Children
  • in reply to Joonas Linkola

    You are correct Joonas, maybe my example would have been more accurate with "Contracts or Agreement Documents".

    I purposefully left the Class Group concept out of my options, as I believe that for a company where M-Files is the main enterprise content management solution they will likely need the class groups to filter out departments content type, like "Sales", "Legal", "HR", etc...

    I have never been a fan of duplicating values (to say the least, actually I'm staying away from them like the plague!)... It makes searching and creating views tricky usually and confuses users. Am I overthinking this?

M-Files
M-Files Support


© 2024 M-Files, All Rights Reserved.