Best Practice & Document Collections

Dear Forum, 

I have use case I would like to ask you for advice about.

We have a department that needs to collate a number of documents (lets say 50-100) for submission to an external party. This department at the moment classifies these documents broadly speaking as "attachments". My idea was to have a document class called Attachment (the broad class would mean that others departments could also utilize this class) and in this particular case we would link to the relevant Object which is the main "parent" of this information.

The idea here is that the:

  1. 100 Attachments could be dragged and dropped into M-Files and saved as doc class = "attachment" which link to a particular object
  2. These 100 attachments can then be collated into a document collection and shared with the relevant parties
  3. Attachments can always be filtered by the linked object which creates a "clean-looking" view for the end user i.e. view by object = document collection etc. 

For those experienced M-Files Users, do you have a better or more efficient way of managing such a case? If yes can you please share your wisdom :) 

Does the above seem too complicated or open to major future issues? Is there an easier method we could employ?

thanks and best regards, 

Parents
  • Hi Jo,

    You may have already encountered this, but remember that a document collection is also unique in that you have two ways of relating documents to it. 

    Method #1) Documents can be dragged and dropped on top of the document collection. This versions up the document collection, and the {document} members can only be seen if the document collection is double clicked, OR the relationship arrow in the list arrow is expanded to see related documents. 

    Otherwise, the related documents are not seen on the document metadata card, nor the document collection metadata card. 

    There are pros and cons of using this method. 

    We do however have a short list of Non-Document Objects (NDOs) for purposes such as Meetings, Projects, Organizations, Programs, and Committees. We've also prevented certain relationships between the objects to ensure always the bigger item is tagged on the smaller and not the other way around - this always has an impact on views *consistency is key. We've put in several measures and guidance for users so we indirectly train them to perform tagging in particular ways. Plus the IML also suggests these objects so they don't need to search for them. Some of these NDOs do permit our users to drag and drop on top of them - but this works for us since the metadata card indicates the relationship, where as the Document Collection does not and only performs the member relationship. 

    For us, we don't generally use this method because of the visibility of related documents. We prefer to see the metadata card, which also impacts views. You can build views where documents are tagged with certain document collections, but I haven't had much success using the member method, so we use Method #2

    Method #2) Tag the document collection on the document's metadata card - a document can be related to multiple document collections, even if the class is different. If all the documents are the same class then a View might be better, as document collections tend to be two additional clicks, which makes more work for the users saving the document and there's room for human error.

    Use Case for a View using Document Collections: I have 2 users who track funding, but I didn't want to create another property & value list for just two users, nor did we want to create an object for them. So instead, they manage about 20 different funds but formulate their Document Collection Names in a certain way (Funding - Funding Name). Then a View looks for documents where: the document metadata filter: Document Collection.Name or Title + Starts with = Funding -   (note the "." [period] to indicate the documents' relationship)

    This way the View isn't limited by the number of documents tagged to a collection.

    It's all in how you approach it. The document collection default number of displayed items can be increased, but I tend to find users still refer and use Document Collections like a folder, rather than leveraging the power of a View. 

    I would investigate:

    • are there patterns to how these document collections are named/used?
    • If the Collections are Class: Submission - could you create a View where all collections with that class are the grouping level? Then as documents are tagged with the Collection they'll filter into the View?

    The View can also be used for dropping documents into one of the grouping levels, then the metadata would pre-populate for your users' attachments.

    This has generally been our approach. While there are benefits of using Method 1 for version control of documents related to a Collection, we did find it tedious to always indicate the document's version relationship. 

    I hope something I've said can be helpful. Have a great weekend!

  • Great points (which I have re-read many times now!!!) thank you for posting - we have not given a lot of consideration to how the document collections are named and used yet. In fact we have not deployed them for general use so I will give some more detailed thought to the two methods in the context of our organization and general working practices. 

  • One additional thing I've just added last week is a configuration rule, that for the Document Collection Object, there is an optional Description (text) property on the metadata card. 

    This is a space where users can describe why they needed the document collection, or its purpose. This is helpful to me as an admin to know why the user wanted the document collection instead of one of the other non-document objects we have.

Reply
  • One additional thing I've just added last week is a configuration rule, that for the Document Collection Object, there is an optional Description (text) property on the metadata card. 

    This is a space where users can describe why they needed the document collection, or its purpose. This is helpful to me as an admin to know why the user wanted the document collection instead of one of the other non-document objects we have.

Children
No Data