Object Nomenclature (Concept)

A Grooper environment consists of many interrelated objects.

The Grooper Wiki's Object Nomenclature defines how Grooper users categorize and refer to different types of Node Objects in a Grooper Repository. Knowing what objects can be added to the Grooper Node Tree and how they are related is a critical part of understanding Grooper itself.

About

In Grooper, understanding the objects within the platform involves recognizing how various elements can serve similar functions and therefore be grouped together based on their shared functionalities. This concept stems from the recognition that disparate objects often perform analogous tasks, albeit with differing characteristics or representations.

By discerning commonalities in functionality across diverse objects, users can streamline their approach to data processing and analysis within Grooper. Rather than treating each object in isolation, users can categorize them based on their functional similarities, thus simplifying management and enhancing efficiency.

This approach fosters a more holistic understanding of the data ecosystem within Grooper, empowering users to devise more effective strategies for data extraction, classification, and interpretation. By recognizing the underlying functional relationships between objects, users can optimize workflows, improve accuracy, and derive deeper insights from their data.

High Level Overview

This article is meant to be a high level overview of all the objects in Grooper and how they're related. If you need more specific information on a particular object, please click the hyperlink for that specific object (as listed in the category's "Related Objects" section) to be taken to an article giving more informatoin on that object.

Batch Objects

In Grooper, "Batch Objects" represent the hierarchical structure of documents being processed. These objects consist of:

inventory_2 Batches

folder Batch Folders

contract Batch Pages

Each serves a distinct function within this hierarchy but are also fundamentally related to each other.

The relationship between these objects is hierarchical in nature.

• The Batch object is the top level
• Each Batch contains: Batch Folders and Batch Pages
  • Batch Folders may contain further Batch Folders to represent subfolders or grouped documents.
  • Or, Batch Folders will contain Batch Pages to represent individual pages of documents.

This structured approach allows Grooper to efficiently manage and process documents at various levels of granularity — from a full batch down to individual pages.

Related Objects

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.

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 Page

contract Batch Page objects represent individual pages within a inventory_2 Batch. The Batch Page object is the most granular unit in the hierarchy of Batch Objects in Grooper.

• Batch Pages are frequently referred to simply as "pages".

They are created in one of two ways:

• Physical pages can be acquired in Grooper by scanning them via the Grooper Desktop application.
• Digital documents are acquired in Grooper as whole objects and represented as Batch Folders. Applying the Split Pages activity on a Batch Folder that represents a digital document will expose Batch Page objects as direct children.

Batch Pages allow Grooper to process and store information at the page level, which is essential for operations that include Image Processing and recognition of text (see Recognize). They enable the system to manage and process each page independently. This is critical for workflows that require detailed page-specific actions or for Batches composed of documents with different processing requirements per page.

Organization Objects

"Oganization Objects" refer to objects used to organize nodes in the Grooper node tree. These objects include:

package_2 Projects

folder_open Folder nodes in the node tree

Template:LocalResourcesIcon Local Resources Folders

Organization Objects are used to store resources at one level of the node tree or another. They may be very generic organizational tools (in the case of Folder nodes) or more specialized (in the case of Projects and Local Resources Folders).

• Folder objects refer to both:
  • The main six folder nodes in the node tree (Batches, Projects, Processes, Queues, File Stores and Machines)
  • Any folder added to the node tree to organize nodes.
• The Project object is the primary container for design components in Grooper. It stores resources used to process document content (like a Content Model) but not document content itself (like Batch Folders).
• The Local Resources Folder object is a specialized folder added to Content Types (e.g. Content Models and Document Types). It houses resources utilized for that Content Type and its decedents (like Data Rules and Data Types).

Related Objects

Folder

folder_open Folder objects refer to the various kinds of organizational folders in the node tree. Please do not confuse "Folder" with "Batch Folder". These are two different things. A Batch Folder is an integral part of the Batch hierarchy and used to represent a "document" in Grooper. A Folder is just a folder.

Local Resources Folder

Template:LocalResourcesIcon A Local Resources Folder is a container object that can only be added to Content Types (e.g. Content Models and Document Types). It is a specialized folder that houses resources used for that Content Type and its Data Model such as Data Rules and Data Types.

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.

Content Type Objects

In Grooper, the "Content Type Objects" consist of:

stacks Content Model ...

collections_bookmark Content Category and ...

description Document Type objects.

Each of these objects serves a distinct function within Grooper's content classification and are related to each other through hierarchical relationships.

The relationship between these objects is established through a heirarchical inheritance system. Content Categories and Document Types are building blocks within a Content Model seen as the "tree". Content Categories act as the "branches". Document Types are the "leaves" of the hierarchy.

"Data Elements" can be defined on each "Content Type Object" and are inherited down the "tree" of heirachy.

• "Data Elements" defined at the Content Model level are applied to all "Content Types" within the Content Model.
• "Data Elements" defined at the Content Category level are applied to all "Content Types" that exist within that specific "branch".
• "Data Elements" defined on a Document Type will apply to that specific "leaf".

These "Content Type Objects" work together in Grooper to enable sophisticated document processing workflows. With different types of documents properly classified, they can have their data extracted and be handled according to the rules and behaviors defined by their respective Document Types within a Content Model hierarchy.

Related Objects

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.

Content Category

collections_bookmark Content Category node objects are containers within a stacks Content Model that hold other Content Categories and description Document Type objects. They allow for further classification and grouping of Document Types within a taxonomy, aiding in the logical structuring of complex document sets. Besides grouping Document Types together, Content Categories also serve to create new branches in a Data Element hierarchy. In most cases Content Categories are used as organizational buckets to group like Document Types together.

Document Type

description Document Type objects represent a distinct type of document, like an invoice or contract. Document Types are created as children of a stacks Content Model or a collections_bookmark Content Category and are used to classify individual folder Batch Folders. Each Document Type in the hierarchy defines the Data Elements and Behaviors that apply to Batch Folders of that specific classification.

What about Form Types and Page Types?

Technically speaking, Form Types and Page Types are also Content Types, but they aren't typically used in the same way. Form Types and Page Types are created automatically when training example documents for classification. They hold the feature weighting data for documents.

• Form Types
  • When a Document Type is trained for classification, the training samples are created as Form Types.
  • Form Types are generated automatically when training documents for Lexical classification (and less commonly for Visual classification).
• Page Types
  • The Page Types are the individual pages of a Form Type. All training weightings are stored on the Page Types for each page of the training document.
  • Page Types are generated automatically when training documents for Lexical classification (and less commonly for Visual classification).

Data Element Objects

The "Data Element Objects" within Grooper consist of:

data_table Data Model ...

variables Data Field ...

insert_page_break Data Section ...

table Data Table and ...

view_column Data Column objects.

Each of these objects has its own function within the data capture and organization framework. These objects are, however, all interconnected within Grooper's data extraction architecture.

The relationship between these "Data Element Objects" is hierarchical and modular.

• The Data Model acts as the overall blueprint for data extraction.
• Data Sections structure the document into logical parts. Data Sections can also serve as simple organizational objects within a Data Model to bucket similar "Data Elements" together.
• Data Tables are incorporated into the model to handle tabular data. Each Data Table comprises Data Columns which specify the format and rules for columnar data extraction.
• Finally, Data Fields are the fundamental units of data of any kind representing individual pieces of non-repeated data within a document. The exception to this is when Data Fields are contained within a "multi instance" Data Section that occurs repeatedly within a document.

Related Objects

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 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 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 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.

Extractor Objects

There are three types of "Extractor Objects" in Grooper:

quick_reference_all Value Reader

pin Data Type

input Field Class

All three of these objects perform a similar function. They are objects that are configured to return data from documents. However, they differ in their configuration and data extraction purpose.

"Extractor Objects" are tools to extract/return data. Ultimately, "Data Elements" are what collects data. They may use extractor objects to help collect data in a Data Model.

To that end, extractor objects serve three purposes:

1. To be re-usable units of extraction
2. To collate data
3. To leverage machine learning algorithms to target data in the flow of text

Re-Usability

"Extractor Objects" are meant to be referenced either by other "Extractor Objects", or more importantly, by "Data Elements". For example, an individual Data Field can be configured on its own to collect a date value, such as the "Received Date" on an invoice. However, what if another Data Field is collectig a different date format, like the "Due Date" on the same invoice? In this case you would create one "Extractor Object", like a Value Reader, to collect any and all date formats. You could then have each Data Field reference that one Value Reader and further configure each individual Data Field to differentiate their specific date value.

Data Collation

Another example would be configuring a Data Type to target entire rows of information within a table of data. Several Value Reader "Extractor Objects" could be made as children of the Data Type, each targeting a specific value within the table row. The parent Data Type would then collate the results of its child Value Reader "Extractor Objects" into one result. A Data Table would then reference the Data Type to collect the appropriate rows of information.

Machine Learning

Many documents contain important pieces of information buried within the flow of text, like a legal document. These types of documents and the data they contain require an entirely different approach to extracting data than a highly structured document like an invoice. For these situations you can use a "trainable" "Extractor Object" known as a Field Class to leverage machine learning algorithms to target important information.

Extractor Objects vs Value Extractors

"Extractor Objects" should not be confused with "Value Extractors". There are many places in Grooper where extraction logic can be applied for one purpose or another. In these cases a "Value Extractor" is chosen to define the logic required to return a desired value. In fact, the "Extractor Objects" themselves each leverage specific "Value Extractors" to define their logic.

"Value Extractor" examples:

• Pattern-Match uses regular expressions to return results.
• Labeled OMR uses a regex and computer vision to return results for checkboxes.
• Other "Value Extractors" may use a combination of "Value Extractors" that work together to return results in specific ways.
  • The Labeled Value "Value Extractor" defines a "Value Extractor" for both its Label Extractor and Value Extractor properties.

However, "Extractor Objects" are used when you need to reference them for their designated strengths:

• re-usbaility
• collation
• machine learning

Related Objects

Value Reader

quick_reference_all Value Reader objects define a single data extraction operation. You set the Extractor Type on the Value Reader that matches the specific data you're aiming to capture. For example, you would use the Pattern Match Extractor Type to return data using regular expression. You would use a Value Reader when you need to extract a single result or list of simple results from a document.

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.

• For example, if you're extracting a date that could appear in multiple formats within a document, you'd use various "Extractor Objects" (each capturing a different format) as children of a Data Type.

The Data Type also defines how to collate results from one or more extractors into a referenceable output. The simplest type of collation (Individual) would just return all individual extractors' results as a list of results.

Data Types are also used for recognizing complex 2D data structures, like address blocks or table rows. Different collation methods would be used in these cases to combine results in different ways.

Field Class

input Field Class node objects are used to find values based on some natural language context near that value. Values are positively or negatively associated with text-based "features" nearby by training the extractor. During extraction, the extractor collects values based on these training weightings.

• Field Classes are most useful when attempting to find values within the flow of natural language.
• Field Classes can be configured to distinguish values within highly structured documents, but this type of extraction is better suited to simpler "Extractor Objects" like quick_reference_all Value Readers or pin Data Types.

Connection Objects

In Grooper, "Connection Objects" play a vital role in integrating external data sources and repositories. They consist of:

cloud CMIS Connection ...

settings_system_daydream CMIS Repository and ...

database Data Connection objects.

Each of these objects serve a unique purpose while also being related through their collaborative use in connecting and managing data across various platforms and databases.

These Connection Objects are related in their collective ability to bridge Grooper with external data sources and content repositories.

• The CMIS Connection object serves as the gateway to multiple content management systems.
• The CMIS Repository object uses this connection to organize and manage document access for those systems.
• The Data Connection object links Grooper to databases, allowing it to perform data lookups and synchronize with external structured data sources.

Together these Connection Objects enable Grooper to extend its data processing capabilities beyond its local domain and integrate seamlessly with external systems for end-to-end document and data management.

Related Objects

CMIS Connection

cloud CMIS Connection node objects provide a standardized way of connecting to various content management systems (CMS). These objects allow Grooper to communicate with multiple external storage platforms, enabling access to documents and content that reside outside of Grooper's immediate environment.

• For those that support the CMIS standard, the CMIS Connection connects to the CMS using the CMIS standard.
• For those that do not, the CMIS Connection normalizes connection and transfer protocol as if they were a CMIS platform.

CMIS Repository

settings_system_daydream CMIS Repository node objects in Grooper allow access to external documents through a cloud CMIS Connection. They allows managing and interacting with those documents within Grooper's framework as if they were local. They are created as a child object of a CMIS Connection and used for various Activities.

Data Connection

database Data Connection node objects define the settings for connecting to and interacting with a database. These interactions may include conducting lookups, exports, or other actions that relate to database management systems (DBMS). Once configured, a Data Connection object can be referenced by other components in Grooper for various DBMS-related activities.

Profile Objects

"Profile Objects" in Grooper serve as pre-configured settings templates used across various stages of document processing, such as scanning, image cleanup, and document separation. These objects, which include:

perm_media IP Profile ...

gallery_thumbnail IP Group ...

image IP Step ...

library_books OCR Profile ...

scanner Scanner Profile and ...

insert_page_break Separation Profile ...

... have their own individual functions but are also related by defining structured approaches to handling documents within Grooper.

By creating distinct profiles for each aspect of the document processing pipeline, Grooper allows for customization and optimization of each step. This standardizes settings across similar document types or processing requirements, which can contribute to consistency and efficiency in processing tasks. These "Profile Objects" collectively establish a comprehensive, repeatable, and optimized workflow for processing documents from the point of capture to the point of data extraction.

Related Objects

IP Profile

perm_media IP Profile node objects detail the operations and parameters for image enhancement and cleanup. These operations improve the accuracy of further processing steps, like the Recognize and Classify Activities.

IP Group

gallery_thumbnail IP Group objects are child objects within perm_media IP Profiles that create a hierarchical structure for organizing image processing commands. IP Groups may contain other IP Groups or image IP Step objects.

IP Step

image IP Step node objects are the basic units within an perm_media IP Profile that define a single image processing operation. IP Steps are performed sequentially within their parent gallery_thumbnail IP Group or IP Profile.

OCR Profile

library_books OCR Profile node objects configure the settings for optical character recognition (OCR) leveraged by the Recognize activity. OCR converts images of text into machine-encoded text. OCR Profile objects influence how effectively text content is recognized and from contract Batch Pages.

Scanner Profile

scanner Scanner Profile node objects store configuration settings for operating a document scanner. Scanner Profiles provide users operating the "Scan Viewer" in Review a quick way to select pre-saved scanner configurations.

Separation Profile

insert_page_break Separation Profile objects contain rules and settings that determine how groupings of scanned pages are separated into individual folder Batch Folders, often using barcodes, blank pages, or patch codes as indicators for separation points.

Queue Objects

"Queue Objects" in Grooper are structures designed to manage and distribute tasks within the document processing workflow. There are two main types of queues:

memory Processing Queue and ...

person_play Review Queue ...

... each with a distinct function but inherently interconnected as they both coordinate the flow of work through Grooper.

The relationship between Processing Queues and Review Queues lies in their roles in managing the workflow and task distribution in Grooper. Both facilitate the progression of document processing from automatic operations to those requiring human intervention.

• Processing Queues handle the automation side of the operation, ensuring that machine tasks are efficiently allocated across the available resources.
• Review Queues oversee the user-driven aspects of the workflow, particularly quality control and verification processes that require manual input.

Together, these queues ensure a smooth transition between automated and manual stages of document processing and help maintain order and efficiency within the system.

Related Objects

Processing Queue

memory Processing Queue node objects are designed for tasks performed by computer Machines and their Activity Processing services. Processing Queues are used to distribute Grooper "Code Activity" tasks among different servers and control the concurrency and/or processing rate of these tasks.

• For example, activities such as Render or Export can be managed so that only one activity instance runs per machine or so multiple instances are processed concurrently, according to the queue configuration.

Review Queue

person_play Review Queue node objects are designated for human-performed tasks. They organizes the Review tasks that require human attention and can distribute these tasks among different groups of users based on the queue's settings. Review Queues can be assigned on the settings Batch Process level to filter work by an entire process or Review Activities at the edit_document Batch Process Step level to filter tasks at a more granular step-based level.

Process Objects

"Process Objects" in Grooper, which include...

settings Batch Process and ...

edit_document Batch Process Step ...

... are closely related in managing and executing a sequence of steps designed to process a collection of documents known as a Batch

Note: The icon for a Batch Process Step will change depending on how you add the object to a Batch Process. If you use the "Add" object-command it will give the Batch Process Step the icon used above. If you use the "Add Activity" object command, it will give the Batch Process Step an icon according the the activity chosen.

Below is an example of a Batch Process with several child Batch Process Steps that were added using the "Add Activity" object-command:

settings Batch Process

description Split Pages

format_letter_spacing_wide Recognize

insert_page_break Separate

unknown_document Classify

export_notes Extract

person_search Review

output Export

inventory_2 Dispose Batch

A Batch Process consists of a series of Batch Process Steps meant to be executed in a particular sequence for a batch of documents. Before a Batch Process can be used in production, it must be "published". Publishing a Batch Process will create a read-only copy in the "Processes" folder of the node tree, making it accessible for production purposes.

In essence, a Batch Process defines the overall workflow for processing documents. It relies on Batch Process Steps to perform each action required during the process. Each Batch Process Step represents a discrete operation, or "activity", within the broader scope of the Batch Process. Batches Processes and Batch Process Steps work together to ensure that documents are handled in a consistent and controlled manner.

Related Objects

Batch Process

settings Batch Process objects are crucial components in Grooper's architecture. A Batch Process orchestrates the document processing strategy and ensures each inventory_2 Batch of documents is managed systematically and efficiently.

• Batch Processes by themselves do nothing. Instead, the workflows they execute are designed by adding child edit_document Batch Process Steps.
• A Batch Process is often referred to as simply a "process".

Batch Process Step

edit_document Batch Process Step objects are specific actions within the sequence defined by a settings Batch Process. A Batch Process Step plays a critical role in automating and managing the flow of documents through the various stages of processing within Grooper.

• Batch Process Steps are frequently referred to as simply "steps".
• Because a single Batch Process Step executes a single Activity configuration, they are often referred to by their referenced Activity as well. For example, a "Recognize step".

Architecture Objects

In Grooper, "Architecture Objects" organize and oversee the infrastructure and framework of the Grooper repository. A "Grooper Repository" is a tree structure of nodes representing both configuration and content objects. These objects include the...

database Root ...

hard_drive File Store and ...

computer Machine objects ...

... each with distinct roles but also working in conjunction to manage resources and information flow within the repository.

The relationship among these "Architecture Objects" is foundational to the operation and scalability of Grooper's document processing capabilities.

• The Root object provides a base structure.
• The Filestore offers a storage utility for files and content.
• The Machine objects represent the hardware resources for performing processing tasks.

Together, they comprise the essential components that underpin the function and manageability of the Grooper ecosystem.

Related Objects

Root

The database Root node object represents the topmost element of the Grooper Repository. It serves as the starting point from which all other objects branch out. It is the anchor point for all other structures within the repository and a necessary element for the organization and linkage of all other objects within Grooper.

File Store

hard_drive File Store objects define a storage location within Grooper where file content associated with nodes are saved. They are crucial for managing the content that forms the basis of the Grooper's processing tasks, allowing for the storage and retrieval of documents, images, and other "files". Not every object in Grooper will have files connected to it, but if it does, those files are stored in the location defined by this object.

Machine

computer Machine node objects represent servers that have connected to the Grooper Repository. They allow for the management of Grooper Service instances and serve as a connection points for processing jobs to be executed on the server hardware. Machine objects are essential for the scaling of processing capabilities and for distributing processing loads across multiple servers.

Miscellaneous Objects

The following ojbects are related only in that they don't fit neatly into the groups defined above in this article.

(un)Related Objects

AI Analyst

An psychology AI Analyst object in Grooper defines a role meant to harness artificial intelligence capabilities, particularly from OpenAI. AI Analyst objects assist with chat sessions and other interactive tasks. This object is set up to act as an AI-driven analyst, which can be configured with specific models such as "gpt-4-1106-preview" to serve as the "brain" of the analyst, performing complex AI functions.

Key properties of an AI Analyst include:

• Model: Defines the OpenAI model that powers the AI Analyst, impacting its cognitive capabilities.
• Enable Code Interpreter: Specifies whether to allow the AI Analyst to write and run Python code in a sandboxed environment. This enables the AI Analyst to process diverse data or generate output like data files and graphs.
• Instructions: Detailed instructions provided to guide the responses and behavior of the AI Analyst during interaction.
• Knowledge: Sets the scope of knowledge available to the AI Analyst to inform its understanding and responses.
• Predefined Messages: A list of predetermined messages that the AI Analyst can use during chat sessions.

The AI Analyst object must have connectivity established with OpenAI. This is done by configuring the Options property on the Root of the Grooper repository. The AI Analyst object can be applied to facilitate AI interactions in chat sessions, offering dynamic responses based on the conversational context, the provided knowledge base, and specific instructions set up for the analyst's behavior .

Control Sheet

document_scanner Control Sheets in Grooper are special pages used to control various aspects of the document scanning process. Control Sheets can serve multiple functions such as:

• separating and classifying documents
• changing image settings dynamically
• create a new folder with specific Content Types
• trigger other actions that affect how documents are handled as they pass through the scanning equipment

Control sheets are pre-printed with barcodes or other markers that Grooper recognizes and uses to perform specific actions based on the presence of the sheet. For instance, when a control sheet instructs the creation of a new folder it can influence the hierarchy within a batch. This enables the management and organization of documents without manual intervention during the Scan activity.

Overall, Control Sheets are an intelligent way to guide the scanning workflow. Control Sheets can ensure that batches of documents are organized and processed according to predefined rules, thereby automating the structuring of scanned content into logical units within Grooper.

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.

The execution of a Data Rule takes place during the Apply Rules activity. Data Rules can be applied at different scopes such as each individual type of "Data Element". The rule can be set to execute conditionally based on a Trigger expression. If the Trigger evaluates to true, the Data Rule's True Action is applied, and if false, its False Action is executed. Data Rules can recursively apply logic to the hierarchy of data within a document instance, enabling complex data transformation and normalization operations that reflect the structure of the extracted data.

Overall, Data Rules in Grooper simplify extractors by separating the data normalization logic from the extraction logic, allowing for flexible and powerful post-extraction data processing .

Lexicon

dictionary Lexicon node objects are dictionary objects that store a list of keys or key-value pairs. Lexicons can define local entries and/or import entries from other Lexicons and even import entries using a Data Connection. The entries in a Lexicon can be utilized in different areas of Grooper, such as data extraction, fuzzy matching, or OCR correction, providing a reference point that enhances the accuracy and consistency of the software's operations.

Object Library

extension Object Library node objects are .NET libraries that contain code files for customizing the functionality of Grooper. These libraries are used for a range of customization and integration tasks, allowing users to extend Grooper's capabilities.

Examples include:

• Adding custom Activities that execute within Batch Processes
• Creating custom commands available during the Review Activity and in the Design page.
• Defining custom methods that can be called from expressions on Data Field and Batch Process Step objects
• Establish custom Grooper Services that perform automated background tasks at regular intervals

Resource File

A Resource File node object in Grooper is essentially a file that is stored as part of a Grooper package_2 Project. It can include various types of files such as text files or XML schema files.