Data Rule (Object)
|
⚠ |
This article was migrated from an older version and has not been updated for the current version of Grooper. This tag will be removed upon article review and update. |
|
This article is about the current version of Grooper. Note that some content may still need to be updated. | ||
| 2025 | 2023 | 2021 |
flowsheet Data Rule objects define the logic for automated data manipulation which occurs after data has been extracted from folder Batch Folders. These rules are applied to normalize or otherwise prepare data collected in a data_table Data Model for downstream processes. Data Rules ensure that extracted data conforms to expected formats or meets certain quality standards.
This allows users to create a conditional hierarchy of actions to take if certain conditions met. These conditions are configured using .NET, LINQ and/or lambda expressions. When the expression is "triggered", either evaluating to "true" or "false", certain actions can be made. These include:
- Calculate Value - This action sets the value of a Data Field or cells a Data Column, using calculate expressions to perform mathematical or concatenation operations of Data Elements.
- Clear Item - This action clears the value of a Data Element.
- Append - This action can add the value of a Data Element to a another, allowing you to add entries to a table, multi-instance section or multi-cardinality field.
- Copy - This action copies or moves the value of a Data Element.
- Parse Value - This action uses a regular expression pattern to return part of a Data Field's value or cell in a Data Column's value.
- Raise Issue - This action adds an issue to the issue log, used for validating a Data Element. This action can also be used to flag the Data Element.
These trigger conditions and subsequent actions set on the Data Rules objects are executed through the Apply Rules activity after data is extracted from an Extract activity. Optionally, Data Model, Data Section, and/or Data Table elements may be configured to execute a Data Rule during a user attended review activity (i.e. Data Review), by setting the object's Validate Rule.
|
|
You may download the ZIP(s) below and upload it into your own Grooper environment (version 2023). The first contains one or more Batches of sample documents. The second contains one or more Projects with resources used in examples throughout this article. |
Glossary
Batch Folder: folder Batch Folder objects are defined as container objects within a inventory_2 Batch that are used to represent and organize both folders and pages. They can hold other Batch Folders or contract Batch Page objects as children. The Batch Folder acts as an organizational unit within a Batch, allowing for a structured approach to managing and processing a collection of documents.
- Batch Folders are frequently referred to simply as "documents".
Batch: inventory_2 Batch objects are fundamental in Grooper's architecture as they are the containers of documents that get moved through Grooper's workflow mechanisms known as settings Batch Processes.
Classify: unknown_document Classify is an Activity that "classifies" folder Batch Folders in a inventory_2 Batch by assigning them a Content Type (e.g. a description Document Type) using patterns, lexical understanding, or rules as defined by a stacks Content Model.
Content Model: stacks Content Model node objects define the taxonomy of document sets in terms of the description Document Type they contain. They also house the Data Elements that appear on each collections_bookmark Content Category and Document Type within them. Content Models serve as the root of a Content Type hierarchy and are crucial for organizing the different types of documents that Grooper can recognize and process.
Correct: abc Correct is an Activity that performs spell correction. It can correct a folder Batch Folder's text content or specific Data Element values to resolve OCR errors, deidentify data or otherwise enhance text data.
Data Column: view_column Data Column node objects are child objects of a table Data Table, representing individual columns and defining the type of data each column holds along with its data extraction properties.
Data Element: Data Element refers to the objects in Grooper used to collect data from a document. These include: data_table Data Models, insert_page_break Data Sections, variables Data Fields, table Data Tables, and view_column Data Columns.
Data Field: variables Data Field node objects are created as child objects of a data_table Data Model. A Data Field is a representation of a single piece of data targeted for extraction on a document.
Data Fields are frequently referred to simply as "fields".
Data Model: data_table Data Model node objects serve as the top-tier structure defining the taxonomy for Data Elements and are leveraged during the Extract Activity to extract data from a folder Batch Folders. They are a hierarchy of Data Elements that sets the stage for the extraction logic and review of data collected from documents.
Data Rule: flowsheet Data Rule objects define the logic for automated data manipulation which occurs after data has been extracted from folder Batch Folders. These rules are applied to normalize or otherwise prepare data collected in a data_table Data Model for downstream processes. Data Rules ensure that extracted data conforms to expected formats or meets certain quality standards.
Data Section: insert_page_break Data Section objects are grouping mechanisms for related variables Data Fields. Data Sections organize and segment child Data Elements into logical divisions of a document based on the structure and semantics of the information the documents contain.
Data Table: table Data Table objects are utilized for extracting repeating data that's formatted in rows and columns, allowing for complex multi-instance data organization that would be present in table-formatted content.
Data Type: pin Data Type objects hold a collection of child, referenced, and locally defined Data Extractors and settings that manage how multiple (even differing) matches from Data Extractors are consolidated (via Collation) into a result set.
Execute: tv_options_edit_channels Execute is an Activity that runs one or more specified object commands. This gives access to a variety of Grooper commands in a settings Batch Process for which there is no Activity, such as the "Sort Children" command for Batch Folders or the "Expand Attachments" command for email attachments.
Expressions: Expressions (not to be confused with regular expressions) are snippets of VB.NET code that expand Grooper's core functionality.
Extract: export_notes Extract is an Activity that retrieves information from folder Batch Folder documents, as defined by Data Elements in a data_table Data Model. This is how Grooper locates unstructured data on your documents and collects it in a structured, usable format.
Project: package_2 Project node objects are the primary containers for configuration nodes within Grooper. The Project is where various processing objects such as stacks Content Models, settings Batch Processes, profile objects, and more are organized and managed. It allows for the encapsulation and modularization of these resources for easier management and reusability.
Review: person_search Review is an Activity that allows user attended review of Grooper's results. This allows human operators to validate processed contract Batch Page and folder Batch Folder content using specialized user interfaces called "Viewers". Different kinds of Viewers assist users in reviewing Grooper's image processing, document classification, data extraction and operating document scanners.
Scope: The Scope property of a edit_document Batch Process Step, as it relates to an Activity, determines at which level in a inventory_2 Batch hierarchy the Activity runs.
About
Some Basics About Expressions
Grooper makes use of expressions to calculate and validate extracted data (or otherwise populate/set data if not otherwise extracted) and use extracted data to populate fields in a Data Model. Traditionally, this is configured on a Data Field object in a Data Model (or in the case of validating or calculating cells in a table, the Data Column object), using the Default Value, Calculated Value, or Is Valid properties.
For example, let's say we have several documents in a Batch. Each one contains W-2 wage reporting forms for various individuals and we want to do some basic tax filing calculation. In order to find someone's total income, it may not be quite as simple as pulling the listed wages from a single W-2. An individual might have multiple W-2s from multiple employers.
If an individual worked for three different employers over the course of a year, their total income would be the wages from all three W-2s added together. This is where expressions come in handy in Grooper. There is no extractible "Total Wages" field on the document. It's just three pages, each page a different W-2. There is no text data for an extractor to return that corresponds to all three W-2's wages field added together.
But we could create a Data Section in our Data Model to return the wages from each individual W-2 form, by adding a "Wages" Data Field and configuring its extraction. Then, we could create a "Total Wages" Data Field and use a Calculated Value expression to add up the results of each "Wages" Data Field in each section (each W-2 in this case).
|
Here, we have a simple Content Model set up to solve the problem described above.
|
| ||
|
| ||
|
|
.png)
Conditional Expressions and Data Rules
You can do a lot with expressions, even applying some conditional logic to their execution. If the condition is met, the expression executes. If not, it doesn't or some other expression executes.
In our example of documents containing W-2 forms we make some assumptions about the document. We assume each document contains a W-2 for a single individual. Each individual should only have one social security number. It would be problematic if their were multiple social security numbers extracted from the W-2 forms. This could indicate there are multiple W-2s for multiple individuals in a single document.
To account for this, you could use a more complex Calculated Value expression to only add up the "Fed Wages" Data Fields if the social security number was the same for each document. If the condition of their only being one social security number for each W-2 is met, the expression to add up the wages would execute. If not, it wouldn't.
This is basic conditional logic. If "x" condition is met, then do "y". If there's only one social security number, then add up all the wages. Otherwise, do nothing (or something else). You could go another step further and add an Is Valid expression to flag the document if the social security numbers didn't match, as well.
However, the more complex a Data Model's data hierarchy (the more Data Sections and Data Tables it has), generally the more complex these conditions tend to be. The more conditions you add for an expression to execute, the more complex the expression becomes. This can result in very cumbersome expressions that are difficult to form and manage.
This is where the Data Rule object really shines. Data Rules allow you to use Trigger expressions to determine one or multiple subsequent Actions to take if that expressions evaluates to true (or false). This is also basic conditional logic. If the trigger expression is true, do the action. Otherwise, do nothing (or a different action). Furthermore, you can more easily create a complex hierarchy of conditions by adding child Data Rules to parent Data Rules. If the trigger expression evaluates to true, the child Data Rules will execute, with their own triggers and even own child Data Rules. This allows for simpler set up, execution, and management of more complex conditional expressions as well as some actions that fall outside normal expressions you can set up in a Data Field or Data Column.
A Basic Example Data Rule
|
| ||
|
Data Rules are executed by the Apply Rules activity. After data is extracted by the Extract activity, any Data Rule referenced by the Apply Rules activity will alter the document's index data according to the Data Rule's configuration. You can test the Data Rule's results in Grooper Design Studio when the Data Rule is selected in the node tree. This will help you verify its configuration, giving you a preview of what would happen if that Data Rule was executed by the Apply Rules activity.
|
|
.png)
The Trigger
The Trigger property serves the purpose of establishing the condition that must be met in order for the Data Rule's action to be taken. These triggering conditions are also set using expressions. These expressions must return a Boolean "true" or "false" value. If the Trigger expression evaluates to "true", the True Action configuration is executed. If the Trigger expression returns "false", the False Action configured is executed (If it is configured. If left blank, no further action will be taken.)
|
In our case, something is wrong with our documents if the W2 forms have more than one social security number. Individuals should only have one social security number. If we added up all the wages for multiple W-2s with mismatched social security numbers, we would not be adding up the total income for an individual correctly. We'd end up with inaccurate data.
|
|
.png)
Luckily, there's an expression we could use to determine if our "W2 Info" Data Section has multiple social security numbers in its sections. This is a good opportunity for a LINQ expression. LINQ (or Language INtegrated Query) expressions are particularly helpful when navigating a Data Model's hierarchical structure to pull information from Data Sections and Data Tables.
Writer's Note: You aren't limited to just LINQ expressions for the Trigger. You can use any expression that returns a Boolean value, including standard.NET expressions, LINQ expressions, and lambda expressions. A LINQ expression just works well for this particular example.
(From sec In W2_Info Select sec.Employee_SSN).Distinct().Count() = 1
Let's break down this expression to understand what's going on.
(From sec In W2_Info Select sec.Employee_SSN).Distinct().Count() = 1
This is the "LINQ-iest" part of the expression. It's querying the extracted instances of our Data Model's objects, to return multiple results.
LINQ expressions always start with From (This indicates the data source from where are you querying the data). Next we declare a type variable we've named sec. We'll use later in the expression to return multiple instances of a Data Field in a Data Section (What you name it doesn't matter, just that you use the same name when you reference the variable later on in the query). The In clause determines the query's scope. We're looking for the "Employee SSN" Data Field in the "W2 Info" Data Section. The "W2 Info" Data Section is our scope. In W2_Info will only query instances (the results of its children Data Fields) in the sections produced by the "W2 Info" Data Section. The Select clause determines what values the query returns (or "selects"). We want information about the "Employee SSN" Data Fields. So, we've entered sec.Employee_SSN. Note, we've referenced the variable we declared at the start of the query, sec to do this.
Now the expression has some information it can work with. In this case, the social security numbers for each W-2 in the document (as returned by the "Employee SSN" Data Field for each section produced by the "W2 Info" Data Section).
(From sec In W2_Info Select sec.Employee_SSN).Distinct().Count() = 1
This part of the expression is counting the number of distinct values returned by the query (Technically, the .Distinct() expression is returning a subset of distinct values in the query's results. Then, the .Count() expression is counting the values in that subset). If the social security number is the same for each W2, there's only one distinct value. This should evaluate to "1". If not, it will be a larger number.
(From sec In W2_Info Select sec.Employee_SSN).Distinct().Count() = 1
This is just an equivalency argument to give us a Boolean "true" or "false" value. If the left side of the argument (the expression (From sec In W2_Info Select sec.Employee_SSN).Distinct().Count()) counts a single unique social security number in each section is equivalent to the right side of the argument (i.e. "1 = 1") it will return "true", otherwise "false".
|
If we use this expression as the Data Rule's Trigger, it will conditionally execute the True Action configured above only if it evaluates as true. Effectively, it will only add up all the wages for each W-2 only when the social security numbers for each W-2 are the same.
|
|
|
|
|
|
.png)
Actions
Once a Data Rule is triggered, what happens next is determined by the True Action and False Action properties. When the Trigger expression evaluates to true, the True Action is executed. When the Trigger expression returns false, the False Action is executed. This determines what action is taken once the trigger condition is met or not met.
This can be one of six choices:
- Calculate Value
- Raise Issue
- Clear Item
- Copy Item
- Parse Value
- Action List
Each action has its own configuration to execute the action, detailed below. If you would like to follow along with this tutorial in Grooper, you can download the zip below and import it into your Grooper environment. It contains the Content Model and Batch used in these examples.
Calculate Value
The Calculate Value action will use a .NET, LINQ or lambda expression to populate a field with the expression's result. The possibilities here are as endless as the capabilities of these expressions. We can perform mathematical operations on numerical data. We can concatenate multiple string fields. We can perform incremental additions to date values. The Calculate Value action allows you to use any configurable expression to manipulate extracted data into a desired result. We've already seen one example of the Calculate Value action in the section of this article above. But let's look at another one.
|
In this example, we have a fairly simple report detailing costs of intangible services related to an oil drilling operation.
|
|
|
|
|
|
A Word of Caution: Overwriting Results
|
There is one important thing to note about the Calculate Value action. The Value Expression's calculated value will overwrite any existing data in a field. For example, take this document.
However, this isn't actually an accurate total. The document is wrong. The grand total of all the values in the "Total" column should add up to "$1,048,050.00" and not what we see here, "$1,111,000.00" |
|
|
|
|
Now, this may be what you want to do, but it may not be what you want to do. What if you don't want to overwrite the "Grand Total" Data Field it it's already populated? What if you only want to use the Calculate Value action to populate the field if it's blank? That's a great opportunity for a Trigger expression! If this were the case, we would only want to execute this Data Rule if the "Grand Total" Data Field is not there. We could use that as the condition to execute the True Action. All we need to do is figure out an expression that would evaluate to true or false if that's the case. The expression
|
|
|
|
Raise Issue
|
⚠ |
Be aware: The Raise Issue action was originally designed with a very narrow scope.
Be aware: The Raise Issue action can be used to flag a document and throw validation warning messages in Review but it CANNOT flag individual fields as errored.
|
The Raise Issue action is useful for data validation. You may want to ensure two fields add up to a third field. You may want to ensure a date on the document is a date in the past or within a day range in the future. You may want to check if two fields are equal to each other. This is the realm of data validation. The Raise Issue action can log information in an issue log if conditions like these are not met.
The Raise Issue action will work in concert with the Trigger expression to log issues. If the Trigger expression returns true, and the Raise Issue action is selected as the True Action it will log a defined message in an issue log. You optionally have the capability to add a message category for issue message as well.
|
In this example, we have a fairly simple report detailing costs of intangible services related to an oil drilling operation. We expect the "Total" column to be the cells in the "Dry Hole" and "Completion" columns added together for each row. We will use the Raise Issue action to verify this.
|
|
|
|
|
|
|
When configuring a Data Rule, the "Diagnostics" tab will give you some more information on what's going on.
|
|
|
|
You may notice the message "Wrong Total" is a little generic. It doesn't give us much information about why the issue was raised. This is why the Log Message property is expression based. It allows you to access some additional information to populate the error message. |
|
Note: The Log Message must evaluate to a string value. This is why we've used the |
|
|
|
|
|
.png)
.png)
Clear Item
The Clear Item action will clear the data in a Data Field if the Trigger condition is met. Clear Item will also clear a Data Column's data if a Data Table is selected as the Scope. This can provide Grooper users a method of removing data from a field or table column if certain conditions are met. For instance, if you know the data is invalid based of the Trigger expression's true/false evaluation, you may prefer to remove the index data rather than keep the invalid data. This could also be a method of redacting sensitive index data after it is exported to a secure database. (Note: For complete redaction, you would probably also want to use the Redact activity to black-bar or white out the document's image and a Correct activity to remove the data from the document's text data as well)
|
For instance, we've seen already situations where this intangibles table's "Grand Total" field on the document does not actually add up to the summation of the "Total" column. We could use a Trigger expression to check if the "Total" column adds up to the "Grand Total" field and clear the extracted "Grand Total" Data Field if it does not add up correctly.
|
|
|
For this document, the extracted values in the "Total" column are themselves accurate.
|
|
|
|
Copy Item
The Copy Item action will copy a field's value and paste it into another field. Optionally, the value can be moved as well (like a cut and paste operation). This can be useful for situations when you need to move data around in a Data Model's hierarchy. This provides an easy way to move a Data Field's value into a Data Section's single or multiple section instances.
|
For example, let's say you need to move the "Grand Total" Data Field into each section instance of a multi-section Data Section.
All you need to configure for the Copy Item action is the Data Field you're copying and what Data Field you're pasting the value to. |
|
|
|
|
|
Parse Value
The Parse Value action allows you to use regular expression to parse an extracted Data Field's text data into another or multiple other Data Fields. This gives you the capability of using a regex pattern to match part of an extracted value's text and populate a different Data Field with its result. In many ways, this is much easier than expression based methods of parsing text data configured on the Data Field object itself.
Before detailing an example of the Parse Value action below, be aware the regex pattern must make use of "Named Groups" to populate the parsed text into Data Fields. The Named Groups' names in the regular expression will need to match the names of the Data Fields they are populating. How to do this will be covered in the example below.
|
In this example, we will parse out an extracted date into component month, day and year fields. You may have a full date on a document, but the database where this data ultimately lives may expect the date's day, month and year separated out into their own table columns. A Data Rule using the Parse Value action can quickly and easily do this for you before the data is exported.
|
|
This will be configured using this Data Rule. |
|
.png)
.png)
If you're not familiar with Named Groups, they are a method of calling out portions of a regular expression in ways Grooper can manipulate them elsewhere. They create sub-instances of an extraction instance named according to however you named the group. Once Grooper has a name it can associate with the sub-instance, it can reference it somewhere else, calling on it to return just that portion of the regular expression.
Groups in regular expression are created with open and closed parenthesis. For example, take the regular expression \d{2}/\d{2}/\d{4} which will match some simple date formats. Bracketing the portion of the regular expression in parenthesis will place it in a group. For example placing parenthesis here, (\d{2})/\d{2}/\d{4} would create a group out of the portion of the regex capturing the month part of the date. (\d{2})/\d{2}/\d{4}
You name the group using the syntax ?<NAME> after the open parenthesis. If you wanted to name this group "Month", you would insert the name tag like so: (?<Month>\d{2})/\d{2}/\d{4}
Now we have a group that is named "Month" for just the two-digit month portion of the date. code>(?<Month>\d{2})/\d{2}/\d{4} Furthermore, since this creates a sub-instance of this regex pattern's extraction result, Grooper has a way it call out just these two digits. In other words, it has a way it can parse the month portion of the full date.
|
We could type this out in our regex pattern, but there are some shortcuts to making Named Groups, in Grooper.
|
| ||
|
| ||
|
As far as Named Groups and Parse Value is concerned, there's a couple things to keep in mind.
|
| ||
|
Now that we have the Parse Value action's Pattern configured, we can test it out.
|
|
Action List
The Action List action gives you a way to execute multiple actions for a single Data Rule. This way, if multiple actions share the same trigger condition, you can just execute all of them in a list, one after the other without creating multiple Data Rule objects. The actions are executed in sequential order, one after the other in the list. This means order of operations can be important. If one action mutates the data in a way that affects another action, you may need to move an action up or down the list.
|
For example, in the previous action examples, we saw three Data Rule configurations that did not use any Trigger configuration whatsoever. So, they share the same trigger condition, just in this case that condition is always "true". Rather than executing three separate Data Rules, we could create a single Data Rule that executes all three actions.
|
|
|
|
|
|
|
|
|
|
Execute Rule
"Execute Rule" is similar to "Action List" in that enables users to perform a series of actions upon a Data Rule. However, unlike "Action List", "Execute Rule" assumes that there is already a separate existing structure of Data Rules, or a single Data Rule for users to reference. In an Action List, users must configure the Actions themselves, while "Execute Rule" requires them to be created and configured already.
|
|
And just like that, our referenced rules were executed! |
|
Data Rule Hierarchy
One of the greatest strengths of the Data Rule object is the ability to create a hierarchy of multiple actions with different conditions. Data Rules can have other Data Rules as their own children. If the parent Data Rule's Trigger expression returns true, not only will its True Action' be applied, but its children Data Rules will also execute. These children Data Rules may have their own Trigger conditions for their actions. Their own child Data Types may even have their own Trigger' expressions. And on down the hierarchy.
This allows you to execute multi-conditional Data Rules with their own conditions, themselves executing only if their parent Data Type's trigger conditions are met. As long as the trigger expression returns true, the next level in the Data Rule hierarchy will execute. If the first Data Rule's Trigger is true, its child Data Rule will execute. If the child Data Rule's Trigger expression is true, its child Data Rule will execute. If its child Data Rule's Trigger is true, its own child Data Rule will execute. And so on down the line.
Let's look at a simple example using some of the actions in our Actions section above. We've seen these actions applied one-by-one, but we're going to create a single Data Type using a hierarchy of conditions to execute multiple actions.
Planning ahead, let's think about what we want to do.
- If the "Dry Hole" column and the "Completion" column doesn't add up to the "Total" column, there's probably something drastically wrong with the data in (or extracted from) the intangibles table. If that is the case, the "Grand Total" extracted is probably wrong. We might just want to stop at that point to prevent ourselves from using incorrect data in one way or another. That document might need a human reviewer to check why the math doesn't add up.
- If the column values do add up right, we probably want to add up the "Total" column to populate for the documents that don't have the Grand Total listed on the page.
- We've already got a multi-conditional Data Rule! The first condition will form the first level in our Data Rule hierarchy, checking to see if the "Dry Hole" column and the "Completion" column add up to the "Total" column. The second condition will form the second level in our Data Rule hierarchy, checking to see if the "Grand Total" Data Field is empty.
- For documents that do have a Grand Total field on the document, we want to check and see if the listed value adds up to all the values in the "Total" column added together. If it doesn't, we'll say we just want to clear the "Grand Total" field entirely.
- But again, we only want to do this assuming the "Dry Hole" and "Completion" columns add up to the "Total" column properly. So, we have another multi-conditional Data Rule, but the second condition will be different than the condition used to check if the "Grand Total" Data Field is empty.
- What if we still want to parse out the date value into day, month and year fields regardless of what's going on in the table? As we will see, this will be no problem for us. We can still use a single Data Rule to execute this action as well, outside of the multi-conditional action execution described above.
You might think of this kind of Data Rule configuration as a container for subsequent Data Rules. No Trigger or Action has been configured, only the Scope at which this rule executes. By itself, this Data Rule will do nothing. But once we add child Data Rules to it and configure them, they surely will. This can be a way of organizing complex Data Rule hierarchies. In our case, it will also serve the purpose of creating a single parent Data Rule which will be used to apply all its child Data Rule configurations. |
|
|
Next we need to add a child Data Rule that does actually do something.
|
|
This isn't actually going to work out for us. But it brings up the importance of Scope when creating a hierarchy of multiple Data Rules. |
|
|
Once you select a narrower scope in a Data Model's hierarchy, you limit your access to the Data Elements within that scope. This can cause problems when attempting to configure subsequent child Data Types Trigger expressions if they require access to Data Fields, Data Tables, or Data Sections outside of this more limited scope.
When adding children Data Rules you can scope down the Data Model's hierarchy but you can't scope up. Since we ultimately will need access to Data Elements like the "Grand Total" Data Field which are outside this Data Table's scope, we need to enlarge the scope of the parent "Total Column Validation" Data Rule. |
|
|
Now that that's out of the way, let's look at how we should have configured the "Total Column Validation" Data Rule.
In this case we will not configure an action. This is just the first condition upon which the next actions second condition are dependent. Adding a child Data Rule to this Data Rule will still require this Trigger expression to be true in order for it to execute. |
|
|
To create the next level of our Data Rule's hierarchy, we will add child Data Rule to the "Total Column Validation" Data Rule. This child Data Rule will only execute if its parent Data Rule's trigger condition is satisfied (if it returns "true"). This will require two triggers for the child Data Rule's action to be applied, both its parent's trigger and its own. This is the basic idea around multi-conditional execution of Data Rules. You effectively daisy-chain trigger conditions as you go down the parent-child node levels.
|
|
|
When it comes time to testing this Data Rule, be sure to execute the right level of the Data Rule hierarchy. In order to ensure all conditions above the Data Rule are also executed, be sure to test (and ultimately execute the Data Rule with the Apply Rules activity) at the highest parent level.
|
|
|
For the next Data Rule added to our hierarchy, we will add the Data Rule configured to recalculate the "Grand Total" Data Field if the extracted "Total" column's values all added together does not match the extracted "Grand Total" on the document. However, we also want this rule to only execute if the "Dry Hole" and "Completion" column values added together equal the "Total" column's values added together. After all, if the "Grand Total" doesn't match up with the summation of the "Total" column, as long as the "Dry Hole" column added with the "Completion" column does add up to the "Total" column, we can just use the values in the table to calculate the "Grand Total" Data Field instead of the wrong value on the document. So, it also needs the trigger condition configured on the "Total Column Validation" Data Rule, but will have its own trigger condition, distinct from the "Total Column Validation" Data Rule's trigger. To do this we will add a Data Rule as another child of the "Total Column Validation" Data Rule. As both children of the "Total Column Validation" Data Rule they are peers or "siblings" in the hierarchy. They will share their parent's trigger condition. If that parent condition is met, they will subsequently execute with their own trigger condition configurations.
|
|
|
When the parent Data Rule executes, its children execute as well, going to the next level in the hierarchy, as long as the Trigger expressions keep evaluating to "true".
|
|
|
What if we also want to do something that doesn't really have anything to do with this conditional execution of Data Rules we've set up here? What if we want to parse out the month, day, and year values from the document's extracted date using the Parse Value action? That doesn't have anything to do with the information in the table values. Whether the column values match up correctly shouldn't impact that action whatsoever. That is not a problem whatsoever. We could easily add a Parse Value Data Rule. We'd just need to make sure it was added to the right level of the hierarchy.
|
|
|
|
.png)
.png)
.png)
An Aside on False Actions
In this article, we've almost exclusively focused on True Actions. If the Trigger expression is true, the configured action is applied. False Actions bear some mention as well. You may want to do something if the trigger condition is not met instead or in combination with an action if it is met.
However, when it comes to Data Rule execution in a hierarchy, whether a True or False Action is configured does not impact whether the next rung of the hierarchy executes. The Trigger expression solely determines this. The next level of the Data Rule's hierarchy will only execute if the Trigger expression returns true. The True or False Action only determines what action is taken for the specific Data Rule. Another way of getting at this, an action is not necessary to continue executing child Data Rules, only that the trigger conditions keep returning true.
|
|
|
|
