Customize captured fields is a configuration module that controls which predefined system fields and sections are included or excluded from Docupath's output, and which of the included fields must be filled before a document can be approved.
It gives you two independent controls over every field. Disabling a field removes it from the output altogether. Leaving a field enabled and marking it Critical keeps it in the output and requires it to carry a value: a reviewer cannot approve or validate a document while a critical field is empty.
Unlike Instruction Builds (which guide what the AI extracts) or Transformations (which reshape extracted values), Customize captured fields operates as an output filter and a completeness check - determining which fields are allowed to appear in API responses, validation screens, stored extraction results, and export payloads, and which of them block approval when empty. It supports scoped configuration at four levels (Global, Country, Organization, Trading Party); every scope that applies to a document is merged, rather than one scope overriding another.
How It Works
What "Disabled" Means
When a field is disabled through Customize captured fields:
The field is removed from API response payloads
The field is not returned to the frontend
The field does not participate in rendering, validation, or UI workflows
The field is excluded from stored extraction outputs, validation screens, exports, and downstream enrichment/mapping stages
Disabling a field is non-destructive: it does not delete stored document data, change AI extraction behavior, or transform values. The AI still extracts the field internally - Customize captured fields simply controls whether it appears in the output.
What "Critical" Means
Any field that is left enabled can also be marked Critical. Critical controls the field's value rather than its visibility: a field marked critical must not be empty when a reviewer approves or validates the document.
Nothing is critical by default. A field becomes critical only when it is explicitly marked in a customization.
Critical applies to enabled fields only. Disabled fields are removed from the document before critical marks are applied, so a disabled field is never enforced.
Critical does not change extraction, enrichment, or the value itself. It only decides whether the document can move forward while that field is empty.
Critical marks are a review-time check only. They are not reflected in the destination format output, so the XML (or other destination payload) is unchanged by marking a field critical.
Section-Level vs. Field-Level Disabling
Customize captured fields supports two levels of control:
Section-Level Disable - Disables an entire section and all predefined fields inside it. Use this when a whole block of fields is irrelevant for the target output. When a section is disabled, no partial exceptions are possible - all fields in that section are removed.
Field-Level Disable - Disables only selected fields within a section. Use this when you need some fields from a section but not others.
Primary Party and Secondary Party sections: Individual fields inside the Primary Party and Secondary Party sections can be disabled, with one exception - the trading party name fields, which are mandatory and always present in output. Because each of these sections always keeps at least one field that cannot be disabled, the section-level toggle for both sections stays locked: the section as a whole can never be switched off, while the fields inside it can be turned on and off individually.
How Scopes Are Merged
A document can match several scopes at once, and Customize captured fields resolves them by merging every matching scope, not by picking a single winning one:
Trading Party Specific - customizations targeted at the document's trading party or trading pair
Organization Specific - customizations targeted at the organization the document is assigned to
Country Specific - customizations targeted at the document's country
Global - the tenant-wide baseline, applying to all documents of a given type
Every customization that applies to the document is combined, and the merge runs in two passes, in this order:
Disabled fields are removed first. The disabled fields from all matching scopes are added together. A field disabled at any scope is removed from the document, and no other scope can bring it back.
Critical marks are applied to what remains. The critical fields from all matching scopes are added together and applied to the fields that survived the first pass. A field marked critical at any scope is critical, and no other scope can un-mark it.
There is no priority order and no first match: both passes are additive. A field marked critical at Global and disabled at Trading Party level is simply disabled - it was removed before the critical pass ran, so there is nothing left to enforce.
When Customizations Are Applied
Customizations apply to a document at all times, not only at the moment it was extracted. The configuration as it stands now is what a reviewer sees on the document and what approval is checked against, so editing a customization also changes how documents processed before the change behave.
Two consequences are worth planning for:
Marking a field critical can block approval on documents that are already sitting in the queue, until the field is filled.
Documents that are already Approved stay approved. They are not re-checked and not reopened, so an approved document can legitimately hold an empty critical field. A later customization change never affects the status of an approved document.
Critical Fields in Tables and Extra Fields
Critical marking is not limited to single-value header fields. It applies to extra fields and to table sections such as Items, Payment Methods, Tax, and Barcodes as well.
In a table, a critical field is enforced per extracted row: each row must carry a value for that field, and the reviewer is told which row numbers are blank. If the document has no rows at all for that table, approval is not blocked. With nothing extracted there is nothing to enforce, and an empty table is not treated as a set of empty critical fields.
What Happens at Approval
Critical fields are checked when a reviewer clicks Approve or Validate:
If any critical field is empty, the action is blocked and a Validations failed modal lists what still needs attention under two headings, Critical fields and Custom validations, so the reviewer can fill the field and try again.
Save and Reject are never blocked. A reviewer can always save changes to a document, or reject it, while critical fields are still empty.
Documents handled by Auto Review are checked the same way before they can be auto-approved. A document with an empty critical field is not auto-approved. Auto Review marks it Failed, the empty critical fields are listed on the document's Validation & Trust tab, and the document is left in the queue for a person. It is not moved to Rejected; it follows the manual approval path from then on.
The same check also covers custom validations configured in Instruction Builds; both appear to the reviewer through the same Validations failed modal.
Multi-Organization Customizations
A single customization can be applied to multiple organizations simultaneously using a multi-select dropdown. This is useful for applying identical field visibility rules across several organizations without duplicating configuration.
Duplicate Protection
The system prevents conflicting configurations by blocking duplicate customizations for the same combination of Document Type + Scope + Target. If a configuration already exists for that combination, the existing one must be edited rather than creating a new entry.
Access Control
Customize captured fields opens on four tabs, Organization, Trading Party, Country and Global, and access is set per tab:
Who | Organization tab | Trading Party tab | Country tab | Global tab |
Admin | Create, edit and delete | Create, edit and delete | Create, edit and delete | Create, edit and delete |
Manager | Create, edit and delete | Create, edit and delete | Not available | Not available |
Custom role | Read and write as granted | Read and write as granted, once the role has read access on Trading Parties | View only, if granted | View only, if granted |
Country and Global customizations are edited by admins only. A custom role can be granted view access to those tabs but never write.
Where a role cannot act, the controls are greyed out with the tooltip "You don't have permission to perform this action" rather than hidden, so a role with read access can see which customizations are in force even when it cannot change them.
Supported Configurations and Options
Configuration | Detail |
Disabling levels | Section-level (entire section), Field-level (specific fields within a section) |
Field marking | A field can be disabled, or left enabled and marked Critical (must not be empty at approval) |
Critical coverage | Header fields, extra fields, and table sections (Items, Payment Methods, Tax, Barcodes) |
Critical enforcement | Blocks Approve and Validate; never blocks Save or Reject |
Scope levels | Global, Country, Organization, Trading Party |
Scope resolution | Additive merge across every matching scope: disabled fields removed first, then critical applied to the remainder |
Document type scoping | Each customization applies to a specific document type |
Multi-organization support | Apply one customization to multiple organizations |
Mandatory fields | The trading party name fields in the Primary Party and Secondary Party sections cannot be disabled; the section toggle for both sections stays locked |
Duplicate prevention | Enforced per Document Type + Scope + Target combination |
Other Technical Specifications
Parameter | Detail |
Field type | Predefined system fields only (not custom fields) |
Enforcement | Backend-level — affects API responses, UI rendering, and export payloads |
Applied at | Every time the document is read and at approval time, using the current configuration; not fixed at extraction |
Critical evaluation | Evaluated in-request when Approve or Validate is used, and on the Auto Review approval path; no critical state is stored on the document |
Destination format output | Unaffected by critical marks; the destination XML does not show or carry criticality |
Approved documents | Never re-evaluated; an approved document keeps its status even if a later change leaves a critical field empty |
Destructiveness | Non-destructive — disabling does not delete data or alter extraction |
Audit logging | All create, update, and delete actions are logged with user, timestamp, scope, target, and affected fields |
Access control | Per tab. Admin: all four tabs. Manager: Organization and Trading Party. Custom role: read and write as granted, with Country and Global view-only |
Notes
Customize captured fields applies to predefined system fields only — custom fields added through other mechanisms are not managed here.
If no customization exists at any scope, Docupath returns the default system field set.
If a document has no country association, Country scope cannot apply, so the system falls back to Trading Party / Organization / Global.
If a document has no organization association, Organization scope cannot apply, so the system falls back to Country / Global.
Disabling fields that connected systems require will break export integrations. Always validate export payloads after making changes.
Data Export Template variables that reference disabled fields resolve to empty values, so keep template mappings aligned with field visibility settings.
Country and Global customizations are edited by admins only. Managers do not have those two tabs. Changes at either scope go through an admin.
Mandatory fields under the Primary Party and Secondary Party sections cannot be disabled.
Disabling fields that downstream systems require will break export integrations — always validate export payloads after making changes.
Data Export Template variables that reference disabled fields resolve to empty values — keep template mappings aligned with field visibility settings.
Custom users cannot see or manage Global or Country scope customizations, even if those scopes affect documents they work with.
The trading party name fields under the Primary Party and Secondary Party sections cannot be disabled, which is why the section toggle for both sections stays locked. Every other field in those sections can be disabled.
Nothing is critical by default. Critical marks only ever come from a customization someone has saved.
Marks are additive across scopes and cannot be reversed by another scope: a field disabled at one scope stays disabled, and a field marked critical at one scope stays critical, regardless of what the other scopes say.
Because customizations apply at all times rather than only at extraction, a change made today can block approval on documents extracted weeks ago. Approved documents are the exception - they stay approved, empty critical fields and all.
A critical field inside a table is only enforced against rows that exist. A table with no extracted rows never blocks approval.
Critical marks are invisible to downstream systems. They do not appear in the destination format output, so integrations are unaffected by marking fields critical.
A document Auto Review refused because of an empty critical field stays on the manual approval path permanently. Filling the field does not restore automatic approval for that document, though later documents from the same trading pair are still eligible.