Best Practice & Document Collections

Question

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: 
 
 100 Attachments could be dragged and dropped into M-Files and s aved as doc class = "attachment" which link to a particular object 
 These 100 attachments can then be collated into a document collection and shared with the relevant parties 
 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,

bright-ideas.dk · Accepted Answer

That depends on circumstances: 
 
 Is there highly sensitive information in the main vault? If yes then either move the sensitive information to another vault or use a separate publishing vault. 
 What is the relation to the external users? If they are few and trusted long term business partners you could probably use the main vault. If they are many and not necessarily trusted then use a publishing vault. 
 Is permissions in the main vault well configured by a competent administrator? It takes quite some effort to control permissions sufficiently to allow external users access to relevant information and nothing more than that. A few mistakes can allow access to more than intended, and it can be difficult to spot such errors. You can also make mistakes in the settings to replicate content to the publishing vault, but it is easy to spot unintended content in a vault that should only have public content.

ssential · Answer

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!

𝕤𝕨𝕖𝕚𝕤𝕖 · Answer

Maybe attach a multi file document and drag the files into it?

Best Practice & Document Collections

Top Replies