Best Practice & Document Collections

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.

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.