Data Rule (Node Type)

This article is about the current version of Grooper.

Note that some content may still need to be updated.

2025

2023

2021

flowsheet Data Rules are used to normalize or otherwise prepare data collected in a data_table Data Model for downstream processes. Data Rules apply conditional logic to data extracted from documents (folder Batch Folders).
Each Data Rule executes a "Data Action" which do things like computing a field's value, parse a field into other fields, perform lookups, and more.

Data Actions can be conditionally executed based on a Data Rule's "Trigger" expression.

A hierarchy of Data Rules can be created to execute multiple Data Actions and perform complex data transformation tasks.

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.

Introduction

A Data Rule is a configurable rule that applies conditional logic to extracted data. Data Rules are typically used after extraction to transform values into the format your downstream systems require, or to enforce business requirements that are easier to express as a rule than as extraction logic.

Unlike extractors (which focus on finding data on the document), Data Rules focus on fixing, moving, combining, and validating the data once it has been captured into a Data Model.

What a Data Rule runs against (scope)

A Data Rule runs against instances of a selected container. The container is chosen using the rule's "Scope" property:

If the "Scope" is set to a Data Model, the rule executes once on the root document instance.
If the "Scope" is set to a Data Section (and the section is multi-instance), the rule executes for each section record (each Section Instance).
If the "Scope" is set to a Data Table, the rule executes for each row (each Table Row Instance).

This is important because many Data Actions operate on fields within the current record/row, and the meaning of “source” and “target” depends on what the rule is scoped to.

Conditional execution (Trigger, True Action, False Action)

A Data Rule can optionally use conditional logic to decide what should happen:

The "Trigger" property must be configured with a Boolean expression.
When "Trigger" evaluates to True:
- The "True Action" runs.
- Any child Data Rules (nested under the current rule) also run.
When "Trigger" evaluates to False:
- The "False Action" runs (if configured).
- Child Data Rules are skipped.
- If no "False Action" is configured, the Data Rule just does not run.

If the Trigger property is blank, the Data Rule will always run.

How Data Rules differ from other conditional components

Data Rules are purpose-built for manipulating and validating extracted values inside the Data Model hierarchy (document, section record, or table row). There are other Grooper components that also use conditional logic (for example, conditional paths in a Batch Process), but those typically control workflow routing or when a step runs. Data Rules control how extracted data is modified within the document's data structure.

When to use Data Rules

You would use Data Rules when you need to normalize, transform, or validate extracted data *after* it has been captured into the Data Model—especially when that logic is easier to manage as rules than as extractor configuration.

Common reasons to use Data Rules include:

Post-extraction cleanup (normalization)
- Trim/standardize formatting (remove extra spaces, normalize case, standardize ID formats).
- Parse composite values into separate fields (for example, split “City, ST ZIP”).
- Build derived fields for export (for example, concatenate multiple fields into a “Full Name” or “Full Address”).

Business-rule validation (beyond “Required”)
- Enforce conditional requirements (for example, “PO Number is required only when Payment Terms = Net 30”).
- Validate relationships between fields (for example, Total = Subtotal + Tax).
- Raise issues when values are present but do not meet business rules (for example, negative amounts, invalid status combinations).

Table and repeating-record cleanup
- Remove blank/noise rows from Data Tables.
- Merge continuation rows/records that should be a single logical item (for example, wrapped line-item descriptions).
- Require key values per row (Quantity, Amount, Item No., etc.).

Enrichment and lookup-driven population
- Run Lookup logic after certain fields are present (for example, look up Vendor ID from Vendor Name).
- Fill dependent fields after you set or correct a “key” value.

Reusable logic and maintainability
- Centralize shared logic into one rule and reuse it with actions like Execute Rule.
- Keep extraction focused on finding data, and keep transformations in rules so they are easier to test and adjust.

Review workflow support
- Automatically fix predictable extraction issues before a user sees the data.
- Raise clear, targeted issues that tell reviewers exactly what needs attention.

In short: use Data Rules when the document data is captured, but it still needs to be made “export-ready” (clean, consistent, complete, and compliant with business rules).

How to configure a Data Rule (Basic Setup)

There are a lot of ways to configure a Data Rule and they can do a lot of different things. To start, here's a very simple example of setting up a Data Rule with a Trigger, True Action, and a False Action.

In Grooper Design, create or select a Data Rule (commonly stored in a Content Type's Local Resources Folder).
Select the Data Rule.
Set the "Scope" to the Data Model, Data Section, or Data Table you want to process.
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set a "True Action" to define what happens when the trigger is met (or always, if Trigger is blank).
(Optional) Set a "False Action" to define what happens when the trigger is not met. If left blank, nothing will happen if the Trigger Condition is not met.
Click over to the "Tester" tab of the Data Rule to Test the rule on a document with extracted data.

Data Actions

Data Actions are the building blocks used in the "True Action" and "False Action" properties of a Data Rule. Actions can be combined and nested to create multi-step logic.

Below are the main Data Actions, in the order commonly presented.

Calculate Value

Calculate Value is a Data Action that evaluates an expression and uses the result to set a value.

In Grooper, this action is implemented as a “calculate and assign” operation:

It can write the result into a specific Data Field (the "Target Field"), and/or
It can store the result into a named custom value (a single saved value you can use later in the workflow).

Purpose
Use Calculate Value when you need to create or normalize a value *after extraction*, based on other values already captured.

Common goals:

Fill or compute a field using other fields (totals, derived values, flags).
Normalize text (trim, reformat, combine pieces).
Set a value only when it's missing (to avoid overwriting user edits).
Compute a “helper value” (custom value) to be used by later steps.

Examples (when you might use it)

Calculate document totals

Example: set “Total” to Subtotal + Tax (or compute a difference).
Useful when totals are missing, unreliable, or you want to standardize the math.

Calculate a line item amount

Example: Line Total = Quantity × Unit Price.
Often used after table cleanup (like merging rows) to ensure values are consistent.

Normalize a field for export

Example: create an export-ready version of a value (removing extra spaces, forcing a consistent format, etc.).

Set a workflow helper value

Example: set a custom value like “IsHighValueInvoice” based on Total, then use that later for routing/flagging.

How to configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Calculate Value.
Expand out the True Action sub properties.
Set the Target Field property to the Data Field where the result of the calculation should be written.
In the Value Expression property, configure a Calculate Value expression to produce the desired output type (string/number/date depending on the Data Field's "Value Type").
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

The Calculate Value action is used in validation when you want the “correct” value to be computed and then either:

filled in automatically (so validation passes once it's set), or
used as the standard that another value must match (often combined with a separate “check” like Raise Issue or a field validation rule).

Because Calculate Value actually changes data, it is usually part of a “fix and then validate” approach rather than a “check only” approach.

If your goal is purely “check and complain” (not change values), then Calculate Value alone isn't ideal. In those cases, use:

field-level validation rules (field “Is Valid” expressions), and/or
Raise Issue / Require Value actions.

A common “strict validation” setup looks like:

Calculate Value computes the expected value (optionally into a helper field or helper value)
A validation step (Raise Issue or field validation) checks whether the captured value matches that expected value

FYI

Note that unlike the Calculated Value property on a Data Field, the Calculate Value True Action does not have the option to set a Calculate Mode. The Calculate Value property cannot, by itself, perform validation. If you need it to perform direct validation, you will need to set the Calculated Value property on a Data Field rather than using a Data Rule.

Clear Item

Clear Item is a Data Action that clears the value(s) of a selected Data Element. Depending on what you select, it can:

Clear a Data Field (sets the field value to blank).
Clear a Data Table (removes all rows from the table instance).
Clear a multi-instance Data Section (removes all records from that collection).
Clear a single-instance Data Section (clears all fields and child elements inside that section).

If there are multiple instances in scope (for example, the same field repeated in many section records), Clear Item clears all of them.

Purpose
Use Clear Item when you need to remove data that is:

Not applicable for the current scenario
Known to be wrong or “leftover”
Should be re-entered / re-extracted

Clear Item is most often used to keep data clean and prevent incorrect values from being exported or reviewed.

How to configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Clear Item.
Expand out the True Action sub properties.
Select the field(s) or element(s) to clear using the Element property.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

Clear Item is used for validation when you want Grooper to treat certain data as “not acceptable” in a given situation, and you want to remove it so it can't accidentally pass review/export.

Essentially, Clear Item is a “fix by removing” validation tool.

Instead of just saying “this is wrong,” it clears the value(s) so the document/row/record becomes obviously incomplete and will either:

fail required-field checks, and/or
trigger a rule that raises an issue, and/or
force a reviewer to re-enter/correct the value.

Clear Item does not automatically create an error message on its own. It “validates” indirectly by:

removing values so required checks fail, or
setting up a condition where another action (Require Value / Raise Issue) can clearly flag the problem.

So a strong validation setup usually looks like one of these:

Clear Item → Require Value (forces correction)
Clear Item → Raise Issue (explains why it was cleared / what to do)
Clear Item as part of a True/False path (keeps data consistent with the situation)

Concat

The Concat Data Action merges (concatenates) adjacent records inside a collection—either a multi-instance Data Section or a Data Table. It is used when extraction produces “split” data that should really be treated as one logical record.

In practical terms, Concat looks at the collection from bottom to top and evaluates a Boolean expression ("Trigger") for each pair of neighboring records. When the trigger is True, it merges the “next” record into the “previous” record, then removes the next record from the collection.

Purpose
Use Concat to clean up extraction output before validation and export by:

Combining “wrapped” or “continued” table rows into a single row.
Merging duplicate/fragmented section records that represent one real-world item.
Preventing downstream totals, counts, and validations from being wrong due to split records.

What gets merged (behavior) When two records are merged:

For simple fields (Data Fields / Data Columns), Concat copies values from the second record into the first only when the first is blank.
For child containers:
- If the child container is a single instance, it recursively fills blanks the same way.
- If the child container is a collection, it moves the child items from the second record into the first record's collection.
After copying/moving, the second record is removed.

This makes Concat a “fill blanks and combine children” merge—not a “overwrite everything” merge.

Duplicate records that belong together
- Symptom: a repeating section is detected twice for the same claim, and one record contains fields missing in the other.
- Goal: combine them so you get one complete record.
- Typical trigger idea: merge when key identifiers match between adjacent records.

Continuation rows identified by missing key fields
- Symptom: extracted table creates extra rows where the “Item No” is blank, but descriptive text is present.
- Goal: merge blank-key rows into the prior row.
- Typical trigger idea: merge when the next row's key field is blank.

Common Trigger examples Use your own field/code names, but the patterns below illustrate how Concat is designed to work (note the use of the “next record” parameter).

Merge when key values match:

 Claim_No = NextItem.Claim_No AND Patient_Name = NextItem.Patient_Name

Merge when the next record is missing a key field:

 NOT NextItem.Service_Date

Merge when descriptions match:

 Description = NextItem.Description

Merge when invoice number matches and next amount is zero:

 Invoice_No = NextItem.Invoice_No AND NextItem.Amount = 0

How to Configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Concat.
Expand out the True Action sub properties.
Set "Collection" to the target Data Table or multi-instance Data Section you want to process.
Set "Parameter Name" (default is NextItem).
Set "Trigger" to the Boolean expression that decides whether two adjacent records should merge. Use the "Parameter Name" variable to reference fields from the next record (for example NextItem.Amount).
- Note that this is different from the Trigger property that determines when the Data Rule will run.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.
- Execute the Data Rule and confirm rows/records merge as expected.
- If too many records merge, tighten the "Trigger" (add more conditions).
- If too few records merge, loosen the "Trigger" (remove unnecessary conditions) or ensure the correct fields are being referenced.
(Recommended) Add a validation follow-up:
- After Concat, use Require Value or Raise Issue rules/actions to enforce that the final merged records contain required values (Qty, Amount, IDs, etc.).

Tips

Concat only merges adjacent records. If matching records are separated by another record, they will not merge.
Because it processes in reverse order, Concat is well-suited to “continuation row goes into the row above” table cleanup.
Keep the "Trigger" specific—overly broad triggers can accidentally merge legitimate rows/records.

Validation usage

The Concat Data Action is used in validation when you need to “fix the structure” of repeating data (tables or repeating sections) before you can reliably validate it.

In other words, Concat helps validation by making sure Grooper is validating the “real” records/rows—not broken or duplicated ones.

Concat itself is not a “this is wrong” check. It's a “make the data shape correct” action. So it is usually placed:

at the beginning of a validation rule chain, or
as the first step in an Action List, followed by actual validation actions like Require Value or Raise Issue.

Copy

Copy is a Data Action that transfers data from one Data Element to another. You can copy:

a Data Field to another Data Field
a Data Column to another Data Column
a Data Section to another Data Section
a Data Table to another Data Table

It can also be configured as a “move” operation (copy, then clear the source).

A key concept with Copy is whether the source and target are “single” or “repeating” relative to where the rule is running:

Single → Single: copy one value/object into one destination
Single → Many: broadcast one value into every repeating target (for example, copy a header field to all rows)
Many → Single: roll up by copying the first repeating source into a single target
Many → Many (fields only): copy repeating field values to another repeating field (this is only supported for fields/columns)

Purpose
Use Copy when you want to:

duplicate a value into another field used for export or downstream steps
populate repeating data from a single “header” value (broadcast)
map data from one section/table to another (especially when normalizing output)
move data from one place to another (copy then clear)
copy only under certain conditions (using the action's own "Trigger")

How to configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Copy.
Expand out the True Action sub properties.
Set the Source Element property to the Data Element you want to copy.
Set the Target Element property to the Data Element you want to populate with the copied information.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

The Copy Data Action is used in validation when you want to keep data consistent across fields, rows, or records so that required-field checks and business rules can be evaluated reliably.

Unlike “check-only” actions (like Raise Issue), Copy is a “fix-up” action: it changes data so validation can pass (or so validation catches the right problem in the right place).

Copy does not “fail” a document on its own. It usually supports validation by:

making required fields non-blank (so validation can pass), or
ensuring the right field gets validated (preventing false failures), or
ensuring values are aligned correctly before checks run.

So Copy is typically paired with validation actions like:

Require Value (to enforce the field after it’s been populated)
Raise Issue (to report mismatches or bad combinations)
field-level rules (required/valid expressions)

Append

Append is a Data Action that adds new entries into a collection. In Grooper, a “collection” can be:

a Data Table (appending adds rows)
a multi-instance Data Section (appending adds records)
a multi-cardinality Data Field (appending adds values to a list)

Append adds one new entry in the target for each instance in the source. It can also optionally copy child values into the newly added row/record using a list of child “Actions” (mapping actions).

Purpose
Use Append when you need to:

build or expand a table/section/list from another table/section/list
“convert” data from one shape into another (for example, section records into table rows)
add values to a multi-value field (for example, collect multiple IDs into a list)
combine data from multiple sources into a single target collection
prevent duplicate rows/records when appending (using "Distinct")

What Append can do (common combinations)

Appending to multi-cardinality fields (value lists)

From a single-value field → adds 1 value to the list
From another multi-value field → adds all values to the list
From a table column → adds values from each row (effectively building a list)

Appending to tables

From a single-instance section → adds 1 row
From a multi-instance section → adds 1 row per section record
From another table → adds 1 row per source row
Optional: use child "Actions" to populate the target columns

Appending to multi-instance sections

From a single-instance section → adds 1 record
From a multi-instance section → adds 1 record per source record
From a table → adds 1 record per row (using child "Actions" to map columns to fields)

How to configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Append.
Expand out the True Action sub properties.
Set the Source Element property to the container element from which you want to append.
Set the Target Element property to the container element where you want the information appended.
Click the ellipsis icon to the right of the Actions property.
When the Actions window appears, click the "+" icon to add an Action. Add as many actions as fields you want to append to.
Configure each action to populate the appended target fields.
Click "OK" when finished.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

Append is used for validation when you need to make sure the “right set of items” exists in a repeating structure (a table, a repeating section, or a multi-value list) before you check it for completeness or correctness.

It helps validation by creating the rows/records/values that validation rules expect to be there.

Append itself does not “say something is wrong.” Instead, it prepares the data so that validation actions (like Require Value or Raise Issue) can run on a correct, complete structure.

Data Lookup

Data Lookup is a Data Action that runs a configured Lookup Specification to query an external data source (commonly a database, but it could be another provider), then uses the results to:

validate that your captured values match a real record, and/or
populate (enrich) additional fields with authoritative data, and/or
populate a collection (a Data Table or repeating Data Section) with multiple results.

In other words: Data Lookup lets Grooper “look up” information from an outside system using values you already extracted, then bring the matching data back into your document's data.

Purpose
Use Data Lookup when you need any of the following:

Enrichment
- Fill in missing details (customer name/address, vendor ID, product description, etc.) from a trusted source.
Validation-by-reference
- Confirm a value is real/acceptable by checking that it exists in an external system.
Standardization
- Replace “messy” document text with the official version from your system of record.
Population of repeating data
- Bring back many results and fill a table or repeating section (line items, transactions, service history, etc.).

How to configure

Create/select a Data Rule.
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Data Lookup.
Expand out the True Action sub properties.
Set the Lookup property to the type of Lookup you will be performing.
Configure the Lookup sub properties the same way you would for a normal lookup.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

A Data Lookup Data Action is used in validation when you want Grooper to “check against a trusted source” and/or “fill in missing details” *before* you decide whether the data is acceptable.

It helps validation in two main ways:

Enrichment (fill-in)
- The lookup pulls back authoritative values (like Customer Name, Vendor ID, Address, Status) and writes them into your fields.
- After that, your validation rules can require those fields and treat missing results as a problem.

Reference-based validation (is this value real?)
- If a document value (like Customer ID) does not match anything in the external system, the lookup will not populate the expected output fields (or it may return no usable result).
- Your validation then flags the missing/blank output fields (or raises an issue) to tell the reviewer “this ID didn't validate.”

⚠	Important: the Data Lookup action itself is primarily a “run the lookup and apply results” step. In practice, it's almost always paired with a validation step like Require Value or Raise Issue so lookup failures become visible and actionable.

Extract From

Extract From is a Data Action that sets a target Data Field's value by running a configured Value Extractor against the value of another (source) Data Field.

Purpose
Use Extract From when you already have a “raw” value captured into a field, but you need to:

Split a composite value into separate fields (for example, pull a ZIP code out of an address string).
Normalize a field by re-extracting only the portion you want to keep.
Derive a value from another field without re-running full document extraction (you're extracting from the field's value, not the page).

Extract From is especially useful when it's easier to capture a “big chunk” of text reliably, then parse it into smaller pieces using a pattern/list extractor.

Example use cases

Extract Last Name from Full Name
Extract Invoice Number from a longer label string
Extract a tracking number from a notes/comment field

How to Configure

Create/select a Data Rule.
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Extract From.
Expand out the True Action sub properties.
Configure the Source Field property to the field that contains the raw/composite text.
Configure the Target Field property to the field you want to populate.
Configure the Extractor property:
- Choose an extractor type that can parse the source value (commonly a Pattern Match / regex-based extractor, list match, etc.).
- Test the extractor pattern against typical Source Field values to ensure it returns the correct hit.
Set overwrite/miss behavior:
- Set "Prevent Overwrite" = True if you do not want to replace existing target values (for example, user-entered corrections).
- Set "Ignore Miss" = True if you do not want a failed parse to wipe out the target value.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.
- Run extraction so the Source Field is populated.
- Execute the Data Rule and confirm the Target Field is set correctly.
- If the Target Field is an array type, confirm multiple hits combine as expected.

Configuration tips

Extract From will not do anything if the Source Field is blank.
If "Extractor" is not configured, the action will error at runtime—always set it.
Make sure the Data Rule "Scope" matches where the Source/Target fields live (especially for fields inside repeating sections or table rows).

Validation Usage

The Extract From Data Action is used in validation when you need to “cleanly re-parse” a value after it has already been captured, so that the value you validate is the correct piece of text (not the messy raw text).

In other words, Extract From helps validation by turning a “raw” field into a “usable” field. Once the usable field is populated, you can reliably require it, compare it, or use it in other validation logic.

Fill

Fill is a Data Action that runs a selected Fill Method on the current in-scope container (a Data Model, Data Section, or Data Table).

A Data Fill Method is a configurable “populate data” routine stored on a container's "Fill Methods" list. The Fill Data Action simply selects one of those methods (by name) and executes it as part of a Data Rule.

Purpose
Use the Fill Data Action when you want to:

run a specific fill routine after extraction (or after other rule steps) without re-running full extraction
populate missing fields using a fill method that already exists on the container
re-run a fill method after you changed something (for example, after you corrected a key field and now want dependent fields filled)
centralize complex “populate” logic inside a fill method, then call it from multiple rules and triggers

It's especially useful for advanced workflows where “populate” is not a one-time only event, but something you want to run conditionally and in a specific order.

Example use cases

Apply a Fill Method somewhere in a Batch Process other than during Extraction.
After setting a key value, run fill logic to populate dependent fields.
Apply a Fill Method to a specific section record or table row.

How to configure

Ensure a Fill Method is already set up and configured on a container Data Element. Ensure the Fill Method has been named.
- If you only want the Fill Method to run as part of the Data Rule and not at Extraction, make sure the "Trigger" property on your Fill Method is set to "False".
# Create/select a Data Rule.
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Fill.
Expand out the True Action sub properties.
Set the Fill Method Name property to the named Fill Method previously configured.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

The Fill Data Action is used for validation when you need to run a “populate/fix-up routine” first, so the data is in its final expected state before you check it for errors.

It doesn't usually “declare something wrong” by itself—it helps validation by making sure the correct values are present (or normalized) so required checks and business rules can be evaluated correctly.

Why Fill is useful for validation

Validation often depends on data that isn't directly extracted as a final value, such as:

values that must be looked up from a reference source
fields that depend on other fields (derived/calculated fields)
totals that must be computed from line items
normalized formats (dates, IDs) that must be standardized before comparing

A Fill method can do that “prep work” reliably. Then validation runs on the finished data.

Parse Value

Parse Value is a Data Action that takes the value from one Data Field (the "Source Field"), applies a regular expression ("Pattern"), and then copies the captured pieces into other fields that are siblings of the source field (fields that share the same parent container).

It does this using named groups in the regular expression. Each named group is treated like a “destination field name.” If a sibling field exists with the same name (spaces replaced by underscores), that field is populated with the captured text.

Purpose
Use Parse Value when you have a “composite” value in a single field and you need to split it into multiple fields for:

cleaner review (separate, readable fields)
stronger validation (each part can be required/validated independently)
export formatting (systems often want structured values instead of one combined string)

Parse Value is especially useful when the pieces you need are always in a predictable format (commas, hyphens, known ordering, etc.).

Example use cases

Split “City, ST ZIP” into City / State / ZIP fields.
Parse an account string into routing/account components.

How to configure

# Create/select a Data Rule.
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Parse Value.
Expand out the True Action sub properties.
Set the Source Field property to the Data Element containing the combined value.
Open the Pattern editor by clicking the "..." to the right of the property.
Write a RegEx pattern to return the value you want parsed. Use Capture Groups to determine which part of the pattern should be parsed out to different Data Elements. Name each Capture Group after its target element.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

The Parse Value Data Action is used in validation when you need to split a single “combined” field into separate pieces so each piece can be checked on its own.

Once the pieces are separated, you can require them, check their formats, and use them in other “business correctness” rules.

Why Parse Value helps validation Many documents store important data in one line, but validation usually works best when each piece is in its own field. For example:

DOE, JOHN Q
Dallas, TX 75201
ACCT-004512-01

If you validate the whole combined value, it's hard to enforce rules like:

“State must be 2 letters”
“ZIP must be 5 digits (or ZIP+4)”
“Last Name is required”
“Account number must be numeric”

Parse Value solves this by extracting parts into sibling fields using a pattern (regular expression) with named groups.

Raise Issue

Raise Issue is a Data Action that creates an entry in the rule's issue log and marks the current in-scope item as having an error message.

When it runs, it:

evaluates the "Log Message" expression to produce the final message text,
adds a new issue record (with an optional "Category" and optional "Metadata"),
and adds the message as an error on the current item so it is visible during review/validation.

Purpose
Use Raise Issue when you want to:

flag a document/record/row as needing attention,
communicate a clear, human-readable problem description,
record why something is invalid or suspicious (especially for review and auditing),
capture “business correctness” problems that do not map cleanly to a single required field.

Raise Issue is one of the main Data Actions used for validation messaging because it answers: “What's wrong, and why?”

How to configure

# Create/select a Data Rule.
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Required) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
- Not all Data Actions require a Trigger to work, but the Raise Issue does. It must know when to raise the issue.
Set the True Action property to Raise Issue.
Expand out the True Action sub properties.
Set the message details (issue category/source text if available) on the Log Message property.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

⚠	The Raise Issue Action does not highlight the Data Element with the issue. You will need to be detailed in your Log Message as to indicate where the problem lies.

Validation usage

The Raise Issue Data Action is used in validation when you want Grooper to clearly flag a problem and explain it in plain language, instead of (or in addition to) marking a single field as invalid.

In practice, Raise Issue is the “tell the user what is wrong” action.

When it runs, Raise Issue:

adds an item to the Data Rule's issue list (an “issue log” entry), and
adds the message as an error on the current item (so the problem is visible during review/validation).

This makes it ideal for validation because it produces a clear, reviewer-friendly message that can be used to route/flag documents and guide correction.

When Raise Issue is the best validation tool Use Raise Issue for problems that are:

cross-field (the problem is the relationship between fields)
conditional (only wrong in a certain scenario)
not “missing,” but “wrong” (the field has a value, but it's not acceptable)
not tied to one field (the “record” or “row” is the problem)

Where do I see these error messages?

When Raise Issue is executed by the Apply Rules activity, the folder will be flagged if Raise Issue identifies an issue as long as the "Flag Issues" property is enabled.
Issues added to the log are visible from a Data Viewer in Review when inspecting the Error List panel.
PLEASE NOTE: Issues can only be raised at the "container level" (Data Model, Data Section, or Data Table).
- Raise Issue will add the issue for whichever container it is executed against (i.e., its Data Rule's "Scope" configuration).
- Raise Issue cannot flag Data Fields, Data Columns, or individual Data Column cells.

Remove

Remove is a Data Action that deletes records from a collection—either a Data Table (removes rows) or a repeating Data Section (removes section records).

It works by evaluating an optional "Trigger" condition for each record in the selected "Collection":

If "Trigger" is True → that record is removed.
If "Trigger" is blank → all records in the collection are removed.

This action removes the record itself (row/record), not just its field values.

Purpose
Use Remove when you want to clean up extraction results by eliminating rows/records that should not exist, such as:

blank table rows that were falsely detected
header/footer “noise” rows that ended up inside a table
continuation/overflow rows that you don't want to keep (sometimes after Concat)
section records that fail a key requirement (for example, missing an ID)

Remove is most often used as a “table/record cleanup” action before stricter validation or export.

Example use cases

Remove table rows that are blank or are header/footer noise.
Remove repeated section records that fail a quality threshold.

How to configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Remove.
Expand out the True Action sub properties.
Set the Collection property to the parent of the records/rows you want removed.
Use a "Trigger" expression to determine when a row/record should be removed (for example, if a key field is blank).
- The Remove Trigger property is different than the Data Rule Trigger property. The Data Rule Trigger property determines when the whole Data Rule Runs. The Remove Trigger property indicates which records should be removed when the Data Rule is run.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

The Remove Data Action is used in validation when you need to eliminate “records that shouldn’t be validated at all” so they don’t create false errors or pollute totals/record counts.

In simple terms:

Remove is validation by cleanup.

It helps validation by deleting junk rows/records so your “real” validation rules (Require Value, Raise Issue, totals checks, etc.) only run against meaningful data.

Why Remove helps validation

Validation often fails for the wrong reason when extraction produces extra rows/records, such as:

blank table rows created by table detection
header/footer lines captured as rows
noise/garbage rows created by OCR artifacts
repeating section records that are “partial” and not real records

If you validate these extra items, you end up with errors like:

“Quantity is required” on a blank row
“Claim Number is missing” on a section record that shouldn't exist
totals mismatch because bad rows were included

Remove prevents that by deleting the bad items before validation is applied.

Require Value

Require Value is a Data Action that enforces that one or more Data Elements have data present.

It can require:

Data Fields and Data Columns (must have a value)
a Data Table (must exist and have at least one row)
a Data Section (must exist; if it is repeating, it must have at least one record)

When a required element is missing:

the element is marked in error (so it becomes invalid in review/validation), and
an issue is added to the rule results (with optional "Category" and "Metadata").

This is the preferred way to implement conditional “required” logic in Data Rules (instead of using the obsolete Data Rule "Required Elements" property).

Purpose
Use Require Value when you need to enforce “this must be filled in order for the document/record/row to be acceptable,” especially when the requirement is:

conditional (only required in certain situations)
record-based (required per repeating section record)
row-based (required per table row)
more specific than a simple field “required” setting

It is one of the most direct validation actions because it creates a clear, actionable error state on the missing item. Example use cases

Require “Invoice Number” when “Document Type” is Invoice.
Require “Amount” on each line item row.
Require a lookup-populated field after a Data Lookup action.

How to configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Calculate Value.
Expand out the True Action sub properties.
Use the Required Elements property to choose the field(s) to require.
(Optional) Provide a rule-specific message context (for example, include the rule name or field path) in the Log Message property.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

Require Value is used in validation to enforce “this must be present” rules by putting missing data into an error state and logging an issue when required data is not found.

In practical terms, it is one of the most direct validation actions because it does all of the following when something is missing:

Marks the specific Data Field / Data Column as invalid (so the user sees an error on the field)
Flags the container (like a Data Table or Data Section) when the required collection/record doesn't exist
Adds an issue to the rule results (optionally grouped by "Category" and enhanced with "Metadata")

What “Require Value” validates (and how)

Data Fields / Data Columns
- Validation: the field exists and is not blank.
- If missing/blank: the field is marked in error and an issue is logged.

Data Tables
- Validation: the table exists and has at least one row.
- If missing/empty: the table (or its instance) is treated as missing required data and an issue is logged.

Data Sections
- Single-instance section: validation is that the section exists.
- Multi-instance section (repeating): validation is that at least one record exists.

This is why Require Value is useful beyond a simple “required field” setting: it can enforce presence of whole tables/sections and can be applied conditionally.

Run Command

Run Command is a Data Action that executes a selected Command on every instance of a chosen Data Element in the current data context.

It is essentially a way to automate “right-click / context menu” command behavior (the kinds of commands a user could normally run in the Data Grid / review UI), but run it automatically as part of a Data Rule.

Purpose
Use Run Command when you want to:

apply an existing Grooper Command to extracted data automatically (instead of relying on a reviewer to run it)
run the same Command against many items at once (for example, every row in a table, every record in a repeating section, or every instance of a field)
reuse built-in commands (or solution-specific commands) inside rule logic without rebuilding the behavior as a custom set of Data Actions

How to configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Run Command.
Expand out the True Action sub properties.
Select the Data Element where you want to run the command in the Element property.
Set the Command property to the command you want to run.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

⚠	The commands you can run depend on your Scope and Element selections. You can run some commands on a Data Model that you can't run on a Data Section or Data Table.

Validation usage

The Run Command Data Action is used in validation when you want to automatically apply a “standard action” (a Grooper Command) to the data so it becomes easier to validate, or so the validation results are consistent and repeatable.

It doesn't usually “prove” the data is correct by itself. Instead, it runs an operation that a reviewer might normally do manually, so that your rule-based checks (Require Value, Raise Issue, totals checks, etc.) are performed on cleaned-up, standardized data.

Action List

Action List is a Data Action that contains an ordered list of other Data Actions and runs them in sequence as a single unit.

In a Data Rule, you typically assign one action to "True Action" (and optionally one action to "False Action"). Action List is how you run multiple steps when a rule fires.

Purpose
Use Action List to build a clear, repeatable “pipeline” of normalization steps, such as:

Fix/standardize values first (Calculate Value, Extract From, Parse Value, Copy, Concat, etc.).
Then enrich (Data Lookup, Fill, Run Command).
Then validate (Require Value, Raise Issue).
Optionally, finalize cleanup (Clear Item, Remove).

This keeps a single Data Rule readable (one trigger, one “bundle of steps”) and avoids needing many small rules just to run multiple actions.

Examples (when to use it)

Normalize then validate
- Step 1: Extract a clean Invoice Number out of a label field (Extract From).
- Step 2: Copy it into another field used for export (Copy).
- Step 3: Require the export field (Require Value) or raise an issue if missing.

Table cleanup workflow
- Step 1: Concat to merge continuation rows.
- Step 2: Remove rows that are now empty/noise.
- Step 3: Require Value on key columns like Quantity and Amount.

Field cleanup + formatting
- Step 1: Parse Value to split “City, ST ZIP”.
- Step 2: Calculate Value to normalize/format one of the parts.
- Step 3: Require Value on the split fields.

How it behaves (important notes)

Actions run in the order they appear in the list.
If later actions depend on earlier actions (for example, Require Value depends on Data Lookup), put them in that order.
Action List itself is not “validation”; it's a container. Validation behavior comes from what actions you include (Require Value, Raise Issue, etc.).

How to Configure

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Action List.
Expand out the True Action sub properties.
Configure the Action List:
1. In the Action List, add Data Actions in the order you want them to run.
2. Configure each action's key properties (for example "Source Field", "Target Field", "Collection", "Extractor", etc.).
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Practical tips

Keep Action Lists short and focused; use multiple rules (or child rules) when there are distinct decision points.
When troubleshooting, temporarily disable later actions (or move them out) to confirm earlier steps are behaving as expected.
If you need a multi-branch workflow (if/else-if style), prefer using Data Rule Trigger logic with child Data Rules rather than one very large action list.

Validation usage

The Action List Data Action is used in validation when you need validation to happen as a sequence of steps, not as a single check.

It lets you run cleanup, enrichment, and validation actions in the right order so the final validation result is accurate and consistent.

This is important because many validation rules depend on earlier steps. For example, you may need to parse or normalize a value before you can reliably require it, or you may need to run a lookup before you can validate that the lookup succeeded.

Why Action List is useful for validation

Validation often requires a pipeline like:

fix/standardize the data
populate missing dependent values (lookups/fill)
enforce requirements and raise issues

If you omit step 1 or 2, you can get false validation failures (the data might be “valid” after normalization/lookup, but you validated too early). Action List solves this by guaranteeing the order of operations.

Execute Rule

Execute Rule is a Data Action that runs another Data Rule as part of the current rule's action sequence.

This lets you “call” a separate rule from inside a parent rule, so you can reuse the same rule logic in multiple places instead of duplicating actions.

Purpose
Use Execute Rule to:

Modularize complex logic into smaller, easier-to-maintain rules.
Reuse the same normalization/validation logic across multiple parent rules.
Keep a parent rule readable by pushing detailed steps into a “helper” rule.

Important scope requirement The rule you execute must apply to:

the same element as the current rule's scope, or
a descendant of that scope (for example, a rule scoped to a Data Table can be executed from a rule scoped to the Data Model, as long as it is in that Data Model tree).

If the selected rule does not apply to the current target scope (or a descendant), the Execute Rule action will not run it.

Examples (when to use it)

Shared “Normalize vendor” logic
- You have a standard set of steps to clean Vendor Name, run a lookup, and require Vendor ID.
- Put that logic in one rule (for example, “Normalize Vendor”).
- Use Execute Rule from multiple parent rules (different document types or different trigger conditions) to apply the same vendor logic consistently.

Standard “Line item cleanup” used across invoices
- Create a rule scoped to the Line Items Data Table that:
  1. merges continuation rows (Concat),
  2. removes empty rows (Remove),
  3. requires key columns (Require Value).
- In each invoice-type rule, use Execute Rule to run the shared Line Items cleanup rule.

Multi-stage processing
- Parent rule decides “when” to run something (Trigger).
- Execute Rule runs the full block of steps only when needed (instead of embedding a long Action List in every branch).

Step-by-step configuration

Create/select a Data Rule
Set the "Scope" property to the container where the target field exists (Data Model, Data Section, or Data Table row context).
(Optional) Set a Trigger Expression on the Trigger property to define the conditional logic on which the Data Rule will run.
Set the True Action property to Execute Rule.
Expand out the True Action sub properties.
Set the Execute Rule action's "Rule" property to a Data Rule you want it to run.
Save changes to the Data Rule.
Click over to the "Tester" tab to test your Data Action.

Validation usage

The Execute Rule Data Action is used in validation when you want to reuse an existing Data Rule (a “validation module”) as part of another rule's validation workflow.

That helps validation by keeping your validation logic consistent, reusable, and easier to maintain—especially when the same checks must be applied in multiple places.

Why Execute Rule is useful for validation

Execute Rule is most valuable when validation logic is:

shared across multiple document types or multiple scopes (document-level + row-level rules)
multi-step (cleanup → lookup → required checks → issue messages)
maintained centrally (change the validation in one place, and everything that calls it benefits)

Instead of rewriting the same Action List over and over, you put that logic in one “child” rule and execute it from other rules.

Applying Data Rules

There are different ways to apply Data Rules to our model:

The Extract Batch Process Step
The Apply Rules Batch Process Step
The Validate Rule property
The Edit Rule Property
The Run Rule command during Review

You choose the method based on *when* you want the rule to run and *who* should trigger it.

Run Data Rules as part of a Batch Process

Both the Apply Rules and Extract Activities on a Batch Process Step can run Data Rules, but they're used for different “timing” and “intent” in a Batch Process.

The simplest way to choose is:

Run Data Rules on the Extract step when the rules are part of “finishing extraction” and you want the saved extracted data to already be cleaned/validated.
Run Data Rules on the Apply Rules step when you want a separate, dedicated normalization/validation pass (often after extraction, sometimes later), or when you need to re-run rules without re-extracting.

Below is when each one makes the most sense.

The Extract Batch Process Step

You always want the rules to run immediately after extraction
This is “extract → clean up → validate → save” as one combined operation.

Typical examples:
- Merge/clean line items right after they are extracted (ex: Concat to merge wrapped rows, Remove to delete empty rows).
- Standardize formats immediately (dates, phone numbers, IDs) so downstream steps always see consistent formatting.
- Do quick cross-checks that are naturally part of extraction output (ex: flag if a required table row is missing).

You want the saved extraction result to already include rule changes
If someone opens the document later (for Review or Export), you want them to see the “final” cleaned data, not raw extraction output.

You are extracting selectively and want rules applied only to what you just extracted
The Extract step can be configured to only extract certain elements or certain Content Types. If your rule is tightly tied to that extraction run, keeping it on Extract is simpler.

You want Extract to be the “one stop shop” for getting data ready
This is common in straightforward processes: Recognize → Classify → Extract (with post-processing rules) → Review/Export.

Practical note: If rules depend on data that is *not yet available* until later steps (for example, results from a later conversion, external enrichment, or manual data entry), then Extract is usually too early.

The Apply Rules Batch Process

If rules are “a post-extraction quality/normalization pass” or “something you might re-run” sometime later in the Batch Process, put them on Apply Rules.

You want to run rules without re-running extraction
Apply Rules is ideal when extraction is expensive/time-consuming, but you want to:
- adjust the rules, then re-apply them,
- fix data, then re-check it,
- or run a second pass of normalization later in the workflow.

You want a dedicated business-rules / validation phase
Many processes separate:
- Extract = capture what's on the document
- Apply Rules = enforce business requirements and normalization
This keeps responsibilities clearer and makes troubleshooting easier (“Is it an extraction problem, or a rules problem?”).

You need multiple rule passes at different times
Common pattern:

After Extract: light cleanup rules (table cleanup, formatting)
Before Export: strict validation rules (required fields, totals match, conditional requirements)

You want rule execution to be more configurable as a standalone step
Apply Rules has a focused purpose: run the rules you select, and optionally flag issues. That's often easier to adjust than mixing lots of rule logic into Extract.

The Validate Rule property

If you want a rule to run when Grooper is doing its “final check” (validation) and deciding whether the data is acceptable, then set the Data Rule to run with the Validate Rule Property on one of your Data Element Containers.

Typical reasons to use it:

Cross-checks and consistency rules
- Example: “Total must equal Subtotal + Tax.”
Conditional requirements
- Example: “If Payment Method is ACH, Routing Number is required.”
Row/record rules
- Example: “Every line item must have Quantity and Amount.”
Rules that should re-check whenever validation happens
- If a reviewer changes a value, and Grooper re-validates, you want the rule to run again so errors/warnings stay up to date.

What you get:

The rule helps decide what should be marked as wrong (errors) or what should be flagged for attention (issues).
It keeps validation behavior consistent and “always enforced.”

The Edit Rule property

You want a rule to run at the moment the value of the Data Field changes, whether by an automated task or by a human during Review.

Typical reasons to use it:

Auto-formatting / cleanup while typing
- Example: strip extra spaces, standardize phone number formatting, enforce uppercase.
Auto-populate related fields immediately when a key field changes
- Example: user enters Customer Number → immediately fill Customer Name/Address.
“Convenience” rules
- Example: if the user enters a short code, expand it to a full value.

What you get:

A smoother review experience (less manual cleanup).
Immediate normalization so the data is already in the right format before validation/export.

Run Rule during Review

Use this when:

The rule is useful, but not always desired.
You want a person to decide when to apply it.

Example:

A “Clean Up Address” rule that is only needed sometimes.
A “Rebuild Line Items” rule that a Reviewer runs only if the table came in messy.

Why this is a good choice:

It avoids unwanted changes on documents that don't need the rule.

Data Rule examples with False Actions and Hierarchy

The tutorials for each of the Data Actions explained how to configure each one individually, but there weren't too many common use cases or examples of how Data Rules are used. In this section you will find a couple of examples to look through.

False Actions

A False Action adds complexity to the conditional logic of a Data Rule. It tells Grooper what to do if the Trigger condition on a Data Rule is not met. This is why you do not see the False Action property unless a Trigger has been set on the Data Rule.

If the "Trigger" evaluates to True → Grooper runs the "True Action" (and then any child rules).
If the "Trigger" evaluates to False → Grooper runs the "False Action" (if one is set), and it does not run the child rules.

When to use

You use a "False Action" when you don't just want to “do nothing” when the condition is false. You want to actively handle the “not this case” scenario.

Common reasons:

Clear out values that should not exist
- If a certain condition is not true, you may want to remove/blank out dependent fields so they don’t contain incorrect data.
Apply a different action for the opposite case
- For example, one path formats data one way, the other path formats it differently.
Raise an issue only when the condition is false
- For example, “If this required situation is not satisfied, flag it.”
Avoid running child rules unless the condition is true
- If you have child rules that should only run in one scenario, you put them under a rule with a Trigger, and use False Action to handle the “else” case.

How to configure a Data Rule with a False Action

Create or select a Data Rule.
Set the Data Rule "Scope".
Set a "Trigger". A Trigger is required for the False Action property to appear.
Set "True Action" to what should happen when the Trigger is True.
Set "False Action" to what should happen when the Trigger is False.
(Optional) Add child Data Rules under this rule if they should only run when the Trigger is True (because child rules are skipped when the Trigger is False).
Test on sample documents:
- Confirm the True path runs when expected.
- Confirm the False path runs when expected.
- Confirm values aren't being unintentionally cleared/removed in edge cases.

Hierarchy Example

Data Rule hierarchy means you can have a “parent” Data Rule with one or more “child” Data Rules underneath it (like an outline or a decision tree). The parent rule decides what to do first, and then (if appropriate) the child rules run afterward.

Think of it like:

Parent rule: “Should I do the invoice checks, yes or no?”
Child rules: “If yes, do the total check… then do the vendor check… then do the line item checks…”

In other words, a hierarchy lets you break a larger procedure into smaller steps and control which steps run.

When to Use

Data Rule hierarchy is mainly used for three big reasons:

Build “if / then” logic without cramming everything into one rule
- A parent rule can decide whether a set of child rules should run at all.

Make complex rule logic easier to read and maintain
- Instead of one huge Action List with 20 steps, you can group steps into smaller child rules with clear names.

Keep rule behavior organized by level (Document → Section → Table)
- Rule “Scope” controls what a rule runs on (whole document, each record in a repeating section, each row in a table). A hierarchy makes it easier to trigger different checks at different levels in a controlled sequence.

How it works

A parent Data Rule can have a "Trigger":

If the Trigger is True:
- the parent's "True Action" runs
- then its child Data Rules run (in order)
If the Trigger is False:
- the parent's "False Action" runs (if you set one)
- child Data Rules do not run

So the parent rule acts like a “gate” that either allows or blocks the entire set of child rules.

Validation with Data Rules

While Data Rules are commonly used for validation, the Data Rules themselves (for the most part) do not perform validation on their own. Rather, they convert the data to a state where it can be validated by another function. There are certain Data Actions (such as Raise Issue or Require Value) that lend themselves more to direct validation of data.

Common validation patterns with Data Rules

1. Conditional required data Use a rule Trigger (or action logic) to require values only in certain scenarios.

Example: “If Payment Method is ACH, then Routing Number and Account Number must be filled.”
How:
1. Set the Data Rule "Scope" to the container where those fields live (often the Data Model or a Data Section).
2. Set "Trigger" to the condition (for example Payment_Method = "ACH").
3. In "True Action", add Require Value actions for the required fields.
4. (Optional) In "False Action", clear dependent fields (using Clear Item) if they should not be set.

2. Cross-field consistency checks Use a Trigger that detects a mismatch, then raise an issue (and optionally force field errors).

Example: “Total must equal Subtotal + Tax.”
How:
1. Scope the rule to the Data Model (so it can see all three fields).
2. Set "Trigger" to the mismatch condition (for example Total <> (Subtotal + Tax)).
3. In "True Action", use Raise Issue to create a clear message.
4. (Optional) Also use Require Value or Clear Item to force correction, depending on workflow.

3. Per-row validation in tables Scope the rule to a Data Table so it runs once per row (Table Row Instance).

Example: “Each line item must have Quantity and Unit Price.”
How:
1. Set the Data Rule "Scope" to the Data Table.
2. Leave "Trigger" blank (always run), or set it to only validate “real” rows (for example, skip blank rows).
3. In "True Action", use Require Value for the required columns.
4. If you need warnings instead of hard errors, use Raise Issue with a targeted message.

4. Validating lookup/enrichment results A common approach is: enrich first, then validate the result.

Example: “Vendor Name must resolve to a Vendor ID.”
How:
1. Action List:
  1. Run Data Lookup (or Fill).
  2. Then Require Value on Vendor ID (or Raise Issue if missing).

5. Validating repeating records (multi-instance sections) Scope the rule to a multi-instance Data Section so it runs once per record.

Example: “Each Claim record must have Claim Number and Date of Service.”
How:
1. Set "Scope" to the Data Section.
2. Use Require Value per record (and optionally Raise Issue).

What “validation” looks like in practice

Field errors: Actions like Require Value (and sometimes Clear Item as part of an enforcement strategy) cause Field Instances to be marked as error when something is missing/invalid.
Rule issues: Raise Issue records a rule-level problem (often used for cross-field problems where no single field is “wrong,” or where you want a clearer message).

Tips

Choose "Scope" based on what you are validating:
- Document-level checks → Data Model scope
- Record-level checks → Data Section scope
- Row-level checks → Data Table scope
For “hard” validation (must be fixed), prefer Require Value set on the Data Field.
For “soft” validation (flag for review / warning style), prefer Raise Issue Data Action.
Use an Action List when validation needs multiple steps (normalize → lookup/fill → validate).