2023.1:Secondary Types (Property)
Secondary Types allow the application of multiple Content Types to a single Batch Folder.
About
One of the most important questions to ask about a document traveling through Grooper is "what kind of document is this?". Of course, answering this question is represented in Grooper through the Classify activity. Specifically, Classification in Grooper associates a Batch Folder (or document) with a Content Type. Once a Content Type is applied to the folder, Grooper knows which Content Model to leverage for the remaining logical operations concerning the Batch Folder like what to extract from it, among other things.
Historically only one Content Type could be assigned to a Batch Folder, limiting the logical operations that could be applied to it, but with Secondary Types this is no longer a limitation.
A Simple Example
Following we will see a simple example of the role Secondary Types can play.
In the "Multiple Types, Single Document" Project we have two distinct Document Types with their own models, but the accompanying Batch has three documents, and one happens to be a document that could reasonably be seen as either of the two Document Types.
How To
With a general understanding of what Secondary Types are let's now take a look at how to configure them using a couple of examples.
EOB Form with Check
Following is an example where a Batch contains EOB packets. In these packets you may or may not have a check that will come with it. In the cases where it does we want avoid a couple of old ways of doing things that would add complexity. In one case we could Separate the check into its own document. In another case we could have the Data Model contain extraction logic for checks and EOBs all the time. Both of these add unnecessary complexity. With Separation we're attempting to do one of the more challenging things in Grooper that require an extra level of logic and review. If we have the Data Model have extraction for checks and EOBs then often we will have blank Data Elements when there is not a check, and this can be confusing to people doing review and/or require a backend system to contain unnecessary extra fields that would remain blank or null.
What we want to do is avoid this unnecessary complexity altogether, therefore, a packet with checks will not only be assigned an "EOB" Document Type, but also a "Check" Secondary Type when applicable.
Follow the instructions in the screenshots below.
