2023.1:Secondary Types (Property)
|
This article is about an older version of Grooper. Information may be out of date and UI elements may have changed. | |
| 2025 | 2023.1 |
Secondary Types allow the application of multiple Content Types to a single Batch Folder.
About
|
You may download and import the file(s) below into your own Grooper environment (version 2023.1). There is a Batch with the example document(s) discussed in this tutorial, as well as a Project configured according to its instructions.
Given the proprietary nature of SharePoint and Database connections, the connection objects and their configuriations cannot be shared.
|
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.
If you want to investigate the construction of the supplied Projects please feel free to poke around. This article will not cover the configuration of all of its parts, as it is not necessary to understanding the topic at hand, but what is relavent to Secondary Types will be covered.
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.
Understanding the Setup
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.
Viewing Properties to See Secondary Type
Viewing Extraction Results for Document with Applied Secondary Type
Using Content Type Filter to Limit Data Shown in Review
Document Variability and Data Normalization
In the screenshot below you will see three different documents that essentially have the same type of information, but each is laid out differently. The end point for collected data ideally does not have variability and as a result seeks to normalize the variation. However, to ease the work and lessen opportunities for mistakes for those doing review of collected data you would allow them to review the data in as close to a 1to1 way as possible. The model the reviewer interacts with should look just like the document. Long story short, we want to separate the normalization of extracted data from the review of said data.
To accomplish this we will take advantage of another benefit of Secondary Types and have two models. The first model will be as close to the documents as possible, while the second will be the normalized version. We will take advantage of the Convert Data activity which will associate a Secondary Type after the data is first reviewed, then via some expressions convert the information to its "final" form.
User Review of Extracted Data
First off, let's take a look at the setup for the user review. We will focus simply on the "Extract Review" step that is made.
Follow the instructions in the screenshots below.
Convert Data Activity and its Role with Secondary Types
Next we will cover how the Convert Data activity is being leveraged in this model.
Data Rules and Expressions are leveraged so feel free to visit those articles for more information (as well as Expressions Cookbook)
Follow the instructions in the screenshots below.
