Best Practice & Document Collections

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

You cannot share a multifile document with external parties - at least not via Public Link. The same challenge applies to Document Collections. One possible solution is to package all the documents in a single Zip file and send a Public link to the external party so they can download the Zip file.

If the external party has access to the vault it is different story. Then you could simply allow access to your document collection and all documents in that collection.

One thing I also noticed is that the Multi-file document doesn't display a document count in brackets. When a Document collection is used, it does specify X document members, which can be helpful - basically its very easy to check that the user has successfully saved the right number of documents.

Vault access for externals is a whole other topic that I had failed to consider here. bright-ideas.dk would you use a publishing vault here to give externals access to the materials they need or do you allow access to the document collection via your main working vault? 

That depends on circumstances:

1. 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.
2. 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.
3. 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.

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. 

The multi-file document looks useful because in this case the individual metadata properties of each of the documents is not important to the end-user - rather they can all share a common metadata card (and its associated properties).  Thanks for your input here!  The next issue to tackle is sharing with externals! 

bright-ideas.dk Excellent questions and information. Thanks! At the moment our current process has been to zip and email the documents to the externals. I think we will have to compare the two methods and see which one makes the most sense from an efficiency and security perspective. 

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.