Extraction Fields

Extraction fields define what data DocAI Fabric pulls out of each document. They are configured per document class: every class has its own set of fields, and the Extract activity reads a document using the fields defined for its class.

Getting the fields right is the single biggest lever on extraction quality. This article explains the field types, how to open and use the Field Properties dialog, and what every setting in that dialog does.

Field types

Type	What it captures	Typical use
Text	A single free-form value. The value types number, date, and boolean are variations of a simple leaf field.	Invoice number, vendor name, date, total
Choice	A value picked from a fixed list of allowed options.	Currency, document subtype, status
Group	A container that organizes related fields together. It has no value of its own.	An "Address" group holding street, city, and postcode
Repeating group (table)	Multiple rows of structured data. Each child field is a column; each row on the document becomes one entry.	Invoice line items, delivery lines

A repeating group can be laid out in one of three structures, which you set in the dialog:

• List for variable line items, such as invoice rows.
• 2-D Table for a clean rows-by-columns grid.
• Nested for a categorised hierarchy with sub-groups (for example, line items grouped under a category column).

Groups and repeating groups can contain other groups, so you can model hierarchical documents as deeply as the source requires.

Opening the Field Properties dialog

The Field Properties dialog is where you configure an individual field. Open it from:

• The Transaction Viewer (data panel): open a field's menu and choose Properties. For a table, use the table header menu; for a single column, use the column menu's Column Properties.
• Project settings (Extraction Fields): each field or group row has a Properties button.

The dialog header reads Field Properties followed by the field name, and has three tabs: General, Normalization, and Validation. The Normalization and Validation tabs show a badge with the number of rules that involve the field.

note

Changes on the General tab are applied only when you click Save Changes. Rules on the Normalization and Validation tabs are saved immediately through their own dialogs.

General tab

Field Name

The name shown to reviewers. It is also used as a hint during extraction, so a clear, descriptive name (for example, "Invoice Number" rather than "num1") improves results on its own.

Where the value comes from

Two side-by-side choices, and the first is the default. The settings for whichever you pick appear directly below them.

• Extract automatically: the field is included in the extraction prompt and the AI reads the value off the document.
• Fill it from a source: the field is left out of the extraction prompt. Choose a source below (a transaction metadata key, or a property such as the source file name), or leave the value to a business rule (for example, a sum of other fields or a catalog lookup) or to a reviewer.

Picking the second option hides the extraction-specific settings (description, structure, multi-page), because they only steer extraction, and reveals the source picker described under Default value and value sources.

Groups and tables have the same two options, without the source picker: a source fills one value, and a table row has nothing for it to attach to. For a group or table, the second option excludes the whole subtree from extraction.

Field Description

An optional instruction that tells the AI how to find and interpret the value. Add a description only when the field name alone is not enough. Good descriptions cover:

• How the field appears in the document.
• Where to find the value on the page.
• Special formatting or variations to expect.
• Related labels or context clues.

Effective descriptions

• Be specific: "The unique invoice identifier, usually starting with 'INV-'."
• Add location hints: "Usually in the top-right corner of the first page."
• State the expected format: "Date in MM/DD/YYYY format."
• Resolve ambiguity: "The total amount due including tax, not the subtotal."

Two helpers sit alongside the description:

• The AI suggest / improve button (sparkle icon) drafts a description from the field name, or refines the one you have written.
• Add Conditional Description and View All Descriptions let you attach a description that applies only under a specific condition (for example, a particular form year or supplier) without changing the base description. When a condition matches at extraction time, a Modified by policy badge shows which description was applied.

Structure (repeating groups)

For a table, choose how it is laid out on the document: List, 2-D Table, or Nested. This reflects the real layout and informs how the rows are extracted.

Hierarchy roles (nested tables)

For a Nested table, nominate which columns drive the hierarchy:

• Category: the top-level grouping column.
• Subcategory: an optional second-level grouping column.

A column can hold only one role at a time.

Multi-page rows (repeating groups)

The Rows can span multiple pages checkbox controls whether the extractor keeps scanning past a page break. It is on by default: the model is told to scan every page and stop only when no more rows exist. Turn it off for a table you know is confined to a single page.

Choices (choice fields)

Define the options a reviewer may select. Each option is a label you can add, rename, reorder, or remove. Three independent settings shape behavior:

• Default option: the option used whenever extraction returns nothing. Leave it at <not selected> and the field starts empty and stays that way until someone chooses.
• Allow multiple selections: the field stores a comma-separated list, and the model is told more than one option may apply.
• Allow empty selection: the control includes an explicit empty option, and an empty value is treated as acceptable.

None of the three gates another. A field can require a selection at review and still have a default, or allow an empty selection and still start from one.

A defaulted choice keeps the model's confidence and records in its reasoning that the default was applied, so a field the model was unsure about still reaches review.

Renaming the default option follows the rename, and removing it clears the default.

Default value and value sources

A text field can say where its value comes from when the model does not supply one. Extraction and a source are mutually exclusive: a field is either read off the document or taken from somewhere else, never both. The Where the value comes from choice decides which.

With Extract automatically selected, you get a Default value. Enter one and it is used only when the model returns nothing for that field. The model's confidence and reasoning are kept, and the reasoning records that the default was applied and why nothing was found. That matters: a default does not silently become a confident answer, so a field the model was unsure about still surfaces for review under your low-confidence policy.

With Fill it from a source selected, you get Fill value from. The field is never sent to the model, so a source decides its value outright. Confidence is 100%, the reasoning records the source, and the field is confirmed automatically so reviewers are not asked to tick a value nobody typed.

The sources are:

Source	What it reads
Transaction metadata	Any key on the transaction, including everything your import connectors write (email subject, sender, received date, connector name, and so on) and anything you send with the document at upload.
Transaction property	Transaction ID, correlation ID, created at, created by, comment, priority, dataset, project version, origin transaction, page count, document count, source file names, source file count, plus project name, project ID, tenant ID and the processing timestamp.
Document property	Document ID, document type, source file name, page count, document number, and the document's first and last page in the transaction.

For transaction metadata, the key box suggests keys your connectors declare and keys already present on your recent transactions.

Default value is available in both cases, because a source can be empty too: a metadata key that was not supplied on this transaction, or a blank document property. With a source configured, the default is the last resort. Leave it blank to leave the field empty. A source that resolves to nothing never overwrites an existing value and never claims it filled the field.

Switching back to Extract automatically removes the source and keeps the default, since the default applies either way.

Choosing No source (use the default value) is how you keep the field out of extraction and leave it to a business rule or to a reviewer.

Only properties that exist when extraction runs are offered, which is why the list has no review outcomes, SLA state or completion timings: those are decided later. Index columns are excluded too, since they are built from extracted field values.

Values are filled during the extraction step, before normalization rules run, so a rule can still transform the result. A value a reviewer has edited by hand is never overwritten by a fill.

A default here is a starting value, not an enforced one

It is applied once, during extraction. If a reviewer clears the field, it stays cleared: the default was a starting point and the reviewer overrode it.

If you need a value that can never be left empty, use the Default Value or Populate Field From Metadata rule preset instead. Rules are re-evaluated every time the field is edited, so clearing the field makes the rule fill it again. See Defaults and metadata fills: rule or field property?

To make a fill depend on something else in the document, use the Conditional Default Value or Conditional Populate From Metadata rule presets instead, which have a Run Condition. See Business Rules.

Default display (groups)

Controls how a group appears when a transaction is first opened in the viewer. Reviewers can still expand or collapse it manually.

• Auto: expanded only when a field inside needs attention (a rule error or low confidence).
• Expanded: always starts open.
• Collapsed: always starts closed.

Reviewer visibility

Controls how the field appears to a reviewer on the review screen. The field is always extracted (or computed) and always included in exports, regardless of this setting. Visibility only affects the review screen.

Setting	Behavior	When to use
Editable	Shown and editable by reviewers (default).	Any value the AI extracts. Extraction can be wrong, so extracted values should stay correctable.
Read-only	Shown but not editable.	Values owned by a business rule, such as a catalog-lookup record id or a computed total, that should be visible but not edited by hand.
Hidden	Not shown to reviewers at all, but still extracted and exported.	Internal or derived values that reviewers do not need to see.

For a group or repeating group, the setting cascades to everything inside it, and the most restrictive setting wins. To lock a single column of a table without locking the whole table, open Column Properties for that column and set its visibility there.

Rule of thumb

Never make an extracted value read-only or hidden if a reviewer might need to correct it. Use Read-only and Hidden for values a rule produces, not for values the AI reads off the page.

Field ID

The unique identifier for the field, used in business rules and API references. It is read-only; use the copy button to grab it.

Normalization tab

Normalization rules automatically transform a field's value after extraction, before validation and export. Use them to clean up formatting, standardize values, apply a default, or map values to a canonical form.

Rules can start from a preset or be written as a custom rule, and each can be enabled or disabled independently. Rules run in order; you manage their order in the Workflow settings. A rule backed by a catalog lookup is marked with a Catalog badge.

Validation tab

Validation rules check the extracted data. If a rule fails, the transaction is flagged for human review. Rules are organized by scope:

• Field Level: validates a single field value.
• Document Level: cross-field checks within one document.
• Transaction Level: cross-document checks.

As with normalization, rules can come from presets or be custom, can be toggled on and off, and may use catalog lookups. See Business Rules for the full rule model.

Required vs optional fields, and confidence

Extraction always returns a confidence score per value. Low-confidence values are highlighted in the Transaction Viewer so reviewers can check them quickly. Combine this with validation rules to enforce that critical fields (such as an invoice number or total) are always present and well-formed, and route anything questionable to review.

Related

• Projects: document classes and when to split fields across classes.
• Extract activity: how fields are used at run time.
• Business Rules: normalization and validation, including catalog lookups.