Data Element

Class names defined here may be used from style sheets, to set CSS properties for multiple elements using a single selector.

Example Use Cases

• Highlighting Required Fields: Assign a class such as required-field to visually distinguish fields that must be completed by the user.
• Conditional Formatting: Use dynamic class assignment to flag fields with missing or invalid data, or to indicate extraction confidence.
• Section or Table Styling: Apply a class to a Data Section or Data Table to style entire groups of fields, rows, or columns.
• Custom Themes and Branding: Combine 'CSSClass' with global or local style sheets to implement organization-specific branding, accessibility adjustments, or dark mode support.
• Workflow Indicators: Use class names to visually indicate workflow states, such as approved, pending-review, or rejected.

Best Practices

• Consistency: Define reusable class names in your style sheets to promote consistent appearance and behavior across your solution.
• Separation of Concerns: Use 'CSSClass' for presentation and UI logic, not for storing business data.
• Avoid Conflicts: Choose class names that do not conflict with built-in Grooper or third-party CSS to prevent unintended side effects.
• Dynamic Logic: Leverage dynamic class assignment for data-driven UI changes, such as highlighting based on extraction results or user actions.

Additional Notes

• The 'CSSClass' property is available on all Data Elements, including Data Fields, Data Sections, Data Tables, and Data Models.
• CSS class names are case-sensitive and must conform to standard CSS naming conventions.
• For more information and advanced scenarios, see the documentation for "CSS Data Viewer Styling".
• Use the 'CSS' property on a Data Field Container to define custom style rules that reference your class names, or include external style sheets at the Data Model or Content Type level for broader styling control.
• In addition to static class names, you can assign dynamic CSS classes to containers by including a string variable named "CSS_Class" on a Data Model, Data Section, or Data Table. This enables conditional styling based on data values, extraction results, or business logic. For example, you might highlight fields with validation errors or flag rows based on extracted content.

Overview

The 'Visible' property determines if a Data Element—such as a Data Field, Data Section, Data Table, or Data Model—is displayed in the Grooper Data Grid and other user interface components. When set to false, the element is hidden from the UI, but it remains part of the data model and can still participate in extraction, validation, and automation processes.

Behavior and Inheritance

• UI Presentation: If 'Visible' is set to false, the element and its children are not shown in the data entry or review panels. This is useful for fields that are used for internal calculations, lookups, or automation but should not be exposed to end users.
• Data Processing: Hidden elements are still included in extraction, validation, and export operations unless explicitly excluded by other configuration.
• Inheritance: The visibility of a parent element (such as a Data Section or Data Table) affects its descendants. If a container is hidden, all child elements are also hidden in the UI, regardless of their individual 'Visible' settings.
• Overrides: The 'Visible' property can be overridden for specific Content Types using property overrides, allowing you to tailor the UI for different document types or business scenarios.

Example Use Cases

• Internal Fields: Hide fields used for intermediate calculations, lookups, or automation that do not require user review.
• Conditional UI: Use property overrides to show or hide fields based on the Content Type or document classification.
• Simplified Data Entry: Hide advanced or rarely used fields to streamline the user experience for most users, while making them available for administrators or special workflows.
• Section and Table Visibility: Hide entire Data Sections or Data Tables to control the visibility of groups of related fields.

Best Practices

• Use the 'Visible' property to reduce UI clutter and focus user attention on relevant data.
• Combine with property overrides to create context-sensitive user interfaces for different document types.
• Remember that hidden elements are still processed during extraction and validation unless excluded by other means.

> Note: The 'Visible' property only affects user interface presentation. It does not remove the element from the data model or prevent it from being used in automation, scripting, or export.

Can be one of the following types:

The 'Display Label' property allows you to specify a custom label for this Data Field that will be shown in the user interface instead of the default field name.

This is especially useful for presenting user-friendly or context-specific labels, supporting localization, or providing dynamic labeling based on label sets.

How It Works

• If set, the display label appears in the UI (such as data entry forms and review screens) in place of the field's code name.
• If left blank, the field's name is used as the label.
• Enter /auto to enable dynamic labeling based on label sets, allowing the label to change depending on the document context or user selection.
• The display label is primarily used in the web client and may not affect all UI components.

Usage Notes

• The display label does not affect the field's code name, data binding, or extraction logic.
• This property is for presentation only and is ignored by backend processes.
• If label sets are not configured, /auto will fall back to the default field name.

Overview

The 'Rubberband OCR Profile' property specifies the OCR Profile to use when performing "rubberband" OCR operations on this Data Element. Rubberband OCR refers to user-initiated or programmatic extraction of text from a specific, interactively selected region of a document image—typically by drawing a rectangle ("rubberbanding") around the area of interest in the Grooper Data Grid or other UI components.

Behavior and Inheritance

• Profile Selection: If set, this property determines which OCR Profile is used for OCR processing when a user selects a region for ad-hoc text extraction. If not set, the system will use the parent element's 'RubberbandOcrProfile', or fall back to a default profile if none is specified in the hierarchy.
• Granular Control: Assigning different OCR Profiles to individual Data Fields, Data Sections, or Data Tables allows for fine-tuned OCR settings based on the content, language, or expected quality of specific document regions.
• Overrides: The 'RubberbandOcrProfile' property can be overridden for specific Content Types using property overrides, enabling document-type-specific OCR strategies.

Example Use Cases

• Mixed-Language Documents: Assign a different OCR Profile to fields or sections that contain text in a different language or script.
• Specialized Zones: Use a custom OCR Profile for regions with unique formatting, such as barcodes, handwriting, or low-quality print.
• User-Driven Extraction: When users manually select a region for OCR in the UI, the specified profile ensures the most accurate recognition for that context.

Best Practices

• Assign a OCR Profile only when the default or inherited profile is not optimal for the specific data element.
• Use property overrides to adapt OCR settings for specialized document types or scenarios.
• Test the effectiveness of different profiles on representative samples to ensure optimal extraction accuracy.

> Note: The 'Rubberband OCR Profile' property only affects OCR operations performed via region selection (rubberbanding) in the UI or automation. It does not impact standard extraction logic unless that logic explicitly invokes rubberband OCR.