Options
  • State Not Answered
  • +4 person also asked this people also asked this
  • Replies 1 reply
  • Subscribers 14 subscribers
  • Views 248 views
  • Users 0 members are here
Related

Collection: How are they designed to work?

amaury.bianchi

Hello,

I am not familiar with how document collections are supposed to work.

  • Are you supposed to use the same class for the collection as for its document members?
  • If the document members are from different classes, do you use a specific class for the collection or just the "document" class?
  • If you design specific classes for collections, how do you handle the fact that some people will want to use them for documents?
  • How do you ensure the composition of a collection, such as having only invoice documents in an invoice collection?
  • You can only see the documents in the "collection members" that you can only see in M-Files, so it means you are never sure the collection you see is complete. Doesn't that defeat the pupose of the collection?
  • Don't users want to checkout all documents when they checkout a collection?

Anytime I need to use something similar to a document collection, I end up encountering a lot of cons... Is it foolish to simply get rid of this concept and use objects with multi-select properties? 

My main questions are:

  1. Is there a good example where the document collection is the proper way to go?
  2. How do you ensure users are using it properly?

My Example: I tried to implement a document collection for invoices, but the client needed to add an Excel recap file on top of them. So I can't use the Hierarchy Manager easily (siblings states functions). I'd like to add a property to the collection dedicated to the recap file, but that doesn't mean users won't try to put it in the "collection members" property. If I want to filter, then I need a custom property, so it's simpler to use a new object type.

Thank you for your insight.

Amaury

Related posts found : 

community.m-files.com/.../best-practice-document-collections

community.m-files.com/.../classes-solely-for-document-collections

  • 0

    My personal view:

    • Document collections are excellent when used in the right way.  They are often confused with multi-file documents but both do different things.
      • MFDs are for when multiple files share the same metadata and should be versioned as a group (e.g. all checked out together).
      • Document collections are for collating documents into a separate entity that can be managed separately (e.g. the entity is checked out separately from the members, and has its own metadata).  Document collections - in my eyes - are not documents, and the metadata should respect that.
        • Note that other non-document-objects can do similar things, of course...
    • Collection members can be version-specific.  This is very useful if you need to manage that something happened with a specific version of a document; for example maybe "Documents provided to supplier X for project Y on date ABC"; you're modelling a specific thing (the provision of the documents) but relating it to the actual items you are managing, and specifically focused on the version that was involved.
    • There are other ways to relate content that do not involve document collections that are perhaps better, depending upon the use-case.
      • For example, if you need to know all the invoices for Project X then instead of a collection you could have a property named "Project Invoices" on Project X that points to specific documents.  This then appears in the object relationships and the like, and you could even perhaps automate management of these property values.

    As for how users interact with them: it's difficult.  Training, often.  You could use some server-side script to stop document collections being added for certain classes...  But often it's about trying to guide people to use the correct mechanism.

    I'll cede the floor for others to give their 2p though!

M-Files
M-Files Support


© 2024 M-Files, All Rights Reserved.