Data Model (Node Type)

This article is about the current version of Grooper.

Note that some content may still need to be updated.

2025

data_table Data Models are leveraged during the Extract activity to collect data from documents (folder Batch Folders). Data Models are the root of a Data Element hierarchy. The Data Model and its child Data Elements define a schema for data present on a document. The Data Model's configuration (and its child Data Elements' configuration) define data extraction logic and settings for how data is reviewed in a Data Viewer.

You may download the ZIP(s) below and upload it into your own Grooper environment (version 2025). 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.

What is a Data Model?

The Data Model defines the data structure for a Content Type and can live at varying levels of structure, allowing for inheritance if a hierarchy exists. This can be a simple list of Data Fields or a complex hierarchy of sections, subsections, tables and fields.

The Data Model is leveraged by Grooper to extract data from a Batch. All extraction logic (i.e. referencing a Data Extractor to fill a field, performing a database lookup, or generating a calculated field expression) is set on the Data Model or the Data Elements related to the Data Model. It also provides information to the Data Review activity setting expectations for field appearance and behavior (i.e. if a field is required before completing batch validation).

One Data Model can be created for each:

Data context can be critical to build the Data Type and Field Class extractors to populate a Data Model. For more information on this topic, visit the Data Context article.

Data Models in Grooper

Data Models are mainly used in the organization and extraction of data. Inheritance of said data from child elements (Data Fields, Data Tables, Data Sections) plays a vital part of the extraction along with any overrides that may need to be performed. In addition, should users desire a more visually appealing view of their extracted data, they can customize the appearance of any Data Fields, Sections, and/or Tables within the Data Model through the use of CSS Styling. These three topics, extraction, inheritance and overrides, and appearance and styling, are explained below.

Extraction

A Data Model organizes its data using three child element types:

Data Field: Captures a single value, such as an invoice number or date.
Data Section: Groups related fields and tables, supporting hierarchical and repeating structures.
Data Table: Extracts tabular data, such as line items or transaction logs.

During extraction, Grooper uses the Data Model to guide the process. Each child element extracts its data from the document, and the results are fed up to the parent Data Model. The extraction process is typically performed by the "Extract" activity on a Batch Folder. For more information about the Extract Activity, click here.

Inheritance and overrides

Data Models in Grooper support inheritance, allowing a child Data Model to inherit structure and properties from a parent. This enables you to define common data elements once and reuse them across multiple document types. Properties and behaviors can be overridden in child Data Models, providing flexibility to customize extraction, validation, or appearance for specialized scenarios.

For example, you might have a base Data Model for generic invoices, with child Data Models for different invoice formats from different companies. Each child can override specific properties or add new fields as needed, while still inheriting the shared structure.

Appearance and styling

Data Models can be styled to improve visualization and usability in the Grooper UI. You can customize the appearance of Data Fields, Data Sections, and Data Tables by setting properties such as "Display Width", "Alignment", "Placeholder", and "Caption". Styling options help users review and edit extracted data more efficiently, and can make complex documents easier to navigate.

Resource Files (such as CSS) can be linked to a Data Model to further customize the look and feel of data grids and review screens. This allows for tailored user experiences and supports branding or compliance requirements.

For more information on CSS styling, click here.

Here, we can see how a customized Style Sheet property in Grooper can help manage the visual aspect of extracted data, making it cleaner and easier to read.

How to create and configure a Data Model

Creating a Data Model:

To create a new Data Model:
Right-click the desired Content Type in the Grooper tree.
Select the Content Type - Create Data Model command.
A new Data Model will be added as a child of the Content Type.

Configuring a Data Model (adding child elements):

Right-click the Data Model and choose "Add", then choose between the three child objects (Data Field, Data Section, or Data Table).
Name the object.
Click "Execute" to create the child object in the Node Tree.
Use the property grid to set appearance, validation, and extraction options.
- To use inheritance, create child Data Models under a parent and override properties as needed.
To add multiple child objects, right-click the Data Model.
Click "Contents"
Select "Add Multiple Items..."
- Note that you can only add multiples of one child object type - Data Fields, Data Tables, or Data Sections.
Within the Add Window, click "☰" to open the dropdown menu for the Item Type.
Select from Data Field, Data Table, or Data Section.
Next, click "..." to add each entry.
List the names of each object.
Click OK when finished.
Click Execute to add the multiple objects.

Example: Closing Disclosures

Data Models are useful for a wide variety of types of documents, such as invoices, HR documents (such as EOB forms), medical records, etc. Long story short, does your document have text data you want extracted? Then you're going to want a Data Model. Let's walk through the set up, configuration, and testing of extraction with a simple example featuring a Closing Disclosures document.