Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developer.kodexa.ai/llms.txt

Use this file to discover all available pages before exploring further.

Data Forms are the review surface for Tasks inside an Activity. They control how extracted data, document context, validation issues, exceptions, and user actions are presented when the workflow needs a person to make a judgment. They render alongside the spatial document viewer, giving reviewers a structured interface for inspecting, editing, and correcting data that was extracted from documents. Rather than writing Vue components directly, you define a JSON schema that the platform interprets at runtime.

​
Where Data Forms Fit

Data Forms belong to the Activity and Task model:
  1. A Data Definition declares the business data structure you want to extract: data objects, attributes, types, validations, formulas, selection options, and event scripts.
  2. An Activity runs automated work that classifies documents, extracts data, validates results, calls systems, and decides when human judgment is needed.
  3. A Task is created when a person needs to review, correct, approve, or resolve an exception.
  4. A Data Form renders the Task experience, binding the reviewer UI to the Data Definition and the document data produced by the Activity.
Each Data Form is associated with a Data Definition, so the form knows which taxons, attributes, and data objects it can bind to. The Task owns the work item. The Data Form owns the review experience.

​
Key Concepts

  • UINode Tree — A data form is a tree of UINode objects, not a flat list of cards. Each node specifies a component type, optional props, bindings, children, and more.
  • Components — Components are registered by namespace and type (e.g., v2:panel, v2:attributeEditor). Layout components like panel, tabs, row, and col structure the form. Data components like attributeEditor, table, and grid bind to extracted values.
  • Data Binding — Components connect to extracted data through binding expressions. These expressions are evaluated against a data context that contains the document’s data objects and attributes, letting you reference specific taxon paths and attribute values.
  • Scripting — A QuickJS WebAssembly sandbox provides a secure runtime for business logic, validation rules, and computed values. Scripts run isolated from the main application and can respond to form events.
  • Bridge API — The kodexa.* namespace exposes platform capabilities to scripts, including data access, navigation, HTTP requests, and form state management.
  • Extraction Integration — The document viewer supports direct extract (verbatim text selection) and AI extraction (LLM-powered multi-field extraction), both of which feed data back into the form.

​
Your First Data Form

Here is a minimal data form that displays an invoice summary panel with a label and an attribute editor: 
{
  "version": "2",
  "nodes": [
    {
      "component": "v2:panel",
      "props": {
        "title": "Invoice Summary"
      },
      "children": [
        {
          "component": "v2:label",
          "bindings": {
            "text": "dataObject.name"
          }
        },
        {
          "component": "v2:attributeEditor",
          "props": {
            "tagPath": "Invoice/InvoiceNumber"
          }
        }
      ]
    }
  ]
}
The top-level version flag tells the platform which renderer to use. The nodes array contains the root-level UI nodes. The v2:panel component acts as a container with a title bar, and its children array holds a label (bound to the current data object’s name) and an attribute editor (bound to a specific taxon path).
The version: "2" flag is required. When present (or when nodes is a non-empty array), the platform uses the schema renderer. Without it, the form falls back to the legacy V1 card-based renderer.

​
What’s Next

The remaining guides cover each aspect of data forms in detail: