17R2 - Dynamic Reference Constraints for Documents - Constrain by Doc Type?

I'm a big fan of the Dynamic Reference Constraints concept that's coming out in 17R2. However, I have either hit a limitation with it or perhaps am not configuring it properly. Could someone confirm/deny that what I'm trying is possible? Thanks.

Here's the use case (simplified for the purpose of asking some questions):

On a document, I have created an Object reference field. Let's call it "Owning Department." With our document type hierarchy, there are certain document types used by certain departments. For example, our IT team exclusively uses an "SDLC" type while our Manufacturing Group uses a "Batch Record" type. We'd like to limit the list of choices in the "Owning Department" field based on the selected Type, Subtype, Classification, or perhaps the Document Type Group.

In my testing, I was able to successfully filter my "Owning Department" Object Reference field, which contains Site and Type object fields, off of a different controlling Object Reference field called "Site" (site__c). An example of this would be: "site__c CONTAINS {{this.site__c}}." It works as expected, and the "Owning Department" field displays a "Depends on Site" message.

Now that I've proven to myself that I understand the syntax of the VQL constraint, I switch the VQL to this: "type__c CONTAINS {{this.type__v}}." I can successfully save the constraint, but it doesn't appear to do anything. There's no "Depends on Type" message and my list of values is empty. I suspect this is because the Type field is actually
a String type on the object and perhaps that's not an allowable controlling field type.

1) Is it possible to constrain by Type, Subtype, Classification, or Document Type Group?
2) If so, can someone provide an example of the proper syntax?
3) Do the Document Type Detail, Document Type Group, or Document Type Group Detail objects offer any help?

My hope was to utilize this new 17R2 feature to help with our complex Dynamic Access Control requirements, so I'm hoping it's just a matter of me making some mistakes. Please let me know if you have any feedback about how to constrain object reference field by Type. If its not possible in 17R2, I'd think that this would be a very useful enhancement for an upcoming release.



  • Avatar
    Randy Hodge Official comment

    Hi Kevin - Great to hear you're a fan of the new Dynamic Reference Constraints (DRC) for documents!  You've indeed hit a limitation.  In this first implementation DRC does not support filtering by document type.  For your example you would need to fake it by creating a custom object for document type and refer to that object from both the document and Owning Department object. You could then add a DRC on document field owning_department__c...something like "doctype__c CONTAINS {{this.doctype_c}}".  But...that would force users to manually populate doc field, doctype__c, on all documents. Ugh.

    We've seen this request already...actually from our own application teams as well as customers. Would be great to have both dynamic and static filters that support document type.  The dynamic filter would detect a given document's type/subtype/classification and allow that to be used as a criteria in a DRC. Once we introduce the notion of static filters for doc fields (object fields support them already) then you could create a static constraint that filters by a specific doctype/subtype/classification.

    So, to summarize:

    1. Vault doesn't support your scenario today, although you can create a manual approach

    2. Docs DRC support for doctype is in our backlog, with no timeframe as of yet

    3. Docs static reference constraints (SRC) is in our backlog, with no timeframe as of yet.

    Thanks as always for your feedback!

    Randy Hodge, Vault Platform Product Management

  • Avatar
    Kevin O'Brien

    Thanks for the reply Randy.  I agree that adding a custom "Type" field and asking a user to populate it would be a pain.  For now, we can work with what we've got, but I'm looking forward to seeing this Type-driven constraint in the future.  I'll keep an eye out for it.  If you need any specific use cases or other info as the product team starts down this path, don't hesitate to reach out.


Please sign in to leave a comment.