The Customize captured fields feature enables fine-grained control over which extraction fields are visible and which of them must be filled, across your tenant, using four scopes. Customizations can be applied at section-level (show or hide a whole form section) or field-level (control individual data fields) across four scopes: Global (baseline), Country (regional configuration), Organization (org-specific configuration), and Trading Party (partner-specific configuration).
Every field has two independent controls. Disabling removes the field from the document altogether. Leaving it enabled and marking it Critical requires it to carry a value: the document cannot be approved or validated while that field is empty.
Scopes are not a priority chain. Every scope that applies to a document is merged: the disabled fields of all matching scopes are removed first, then the critical marks of all matching scopes are applied to whatever is left. Inside the Primary Party and Secondary Party sections, the trading party name fields cannot be disabled, which keeps the section toggle for both sections locked. Access is set per tab: admins work on all four, managers work on Organization and Trading Party, and a custom role gets read and write per tab as granted, with Country and Global grantable as view only and never as write.
How It Works
Understanding the Scope Merge
A document can match several scopes at the same time - for instance a trading party customization, its organization's customization, its country's customization, and the Global baseline. All of them are applied together:
Global + Country + Organization + Trading Party ↓ 1. Remove every field disabled at ANY of these scopes ↓ 2. Mark critical every remaining field marked critical at ANY of these scopes
Both passes are additive, and the order matters. Disabled wins over critical: a field disabled at one scope and marked critical at another is removed in pass 1, so there is nothing left for pass 2 to enforce. No scope can re-enable a field that another scope disabled, and no scope can un-mark a field that another scope marked critical.
Scopes are therefore layered rather than ranked. Configure Global as the smallest common baseline and use the narrower scopes to add to it, not to undo it.
Global Scope: Defining the Baseline
Navigate to Settings > Customize captured fields
Select the Global tab
View all available sections (Primary Party, Secondary Party, Invoice Details, Line Items, etc.)
Section-level customization:
Toggle sections ON/OFF to show or hide entire form sections
The Primary Party and Secondary Party section toggles are locked, because each keeps at least one field that cannot be disabled
Example: Hide "Tax Details" section if your org doesn't require tax data
Field-level customization:
Expand a section to see individual fields
Toggle individual fields ON/OFF
Fields within hidden sections are automatically hidden
Fields in the Primary Party and Secondary Party sections can be toggled off individually, except the trading party name fields
Critical marking:
Mark any field that stays enabled as Critical when it must never be empty
Critical is not available on a disabled field; the field has to be enabled first
Example: mark the invoice number critical so no document is approved without one
Click Save to apply Global baseline settings
Country Scope: Regional Configuration
Select the Country tab
Choose a country from the dropdown (e.g., "Sweden", "Netherlands", "Germany")
Customize fields and sections for that country:
Disable fields not used in that country (e.g., US state codes for European countries)
Mark fields critical where country-specific regulations require them to be present
Example: mark VAT identification fields critical for EU countries
Settings apply to documents tagged with that country, on top of whatever Global already disables or marks critical
Click Save
Organization Scope: Multi-Org Customization
Select the Organization tab
Use the Multi-organization Selector to choose one or more organizations (sub-orgs)
Customize fields and sections for those organizations:
Different organizations may have different field requirements
Useful for multi-tenant deployments with varying compliance needs
Example: Parent company requires a PO number, so it is marked critical there; the subsidiary leaves it optional
Settings apply to documents routed to the selected organizations, on top of Country and Global
Click Save
Trading Party Scope: Partner-Specific Rules
Select the Trading Party tab
Choose a specific trading party (supplier, customer, partner) from the dropdown
Customize fields and sections for that partner:
Enforce specific data from key suppliers by marking fields critical (e.g., always require SKU or batch number)
Remove fields a partner never provides by disabling them
Align with the partner's data provision capabilities
Example: Vendor A always supplies full line item detail, so those fields are critical for Vendor A only
Settings apply to documents involving that trading party, on top of Organization, Country, and Global
Click Save
Fields That Cannot Be Disabled
The trading party name fields in the Primary Party and Secondary Party sections are mandatory and cannot be disabled at any scope. Every other field in those sections can be disabled.
Because those sections always retain at least one field, their section-level toggles stay locked - the sections themselves can never be switched off, even though their contents can be reduced field by field. All other sections (Invoice Details, Tax Details, Line Items, etc.) can be disabled outright.
Overlapping Customizations
Because every matching scope is merged, two scopes touching the same field do not conflict in the sense of one winning. A field disabled anywhere is disabled; a field marked critical anywhere, and not disabled, is critical.
Docupath shows which scope a setting comes from, so you can tell where a disabled field or a critical mark was configured when you need to change it.
Duplicate customizations for the same combination of Document Type, Scope, and Target are blocked: edit the existing entry rather than creating a second one.
When Customizations Take Effect
Customizations are applied to documents at all times, not only at the point of extraction. What a reviewer sees on a document, and what approval is checked against, is the configuration as it stands right now.
Editing a customization changes the behavior of documents that were already processed, as well as new ones. A field marked critical today can block approval on a document extracted last week.
Approved documents stay approved. They are not re-evaluated, so an approved document may hold an empty critical field without its status changing.
Critical Fields in Tables and Extra Fields
Critical marking works the same way for extra fields and for table sections such as Items, Payment Methods, Tax, and Barcodes. In a table, each extracted row must carry a value for the critical field.
If a table has no extracted rows at all, it does not block approval. There is nothing extracted to check, so an empty table is not read as a set of empty critical fields.
What a Reviewer Sees
When a reviewer clicks Approve or Validate on a document with an empty critical field, the action is blocked and a Validations failed modal lists what needs attention. Save and Reject are never blocked.
On the Auto Review path, 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 rather than moved to Rejected. It continues through manual review from then on.
Testing Customizations Across Scopes
Before deploying customizations to production:
Test in a sandbox environment:
Create test documents with various combinations of country, organization, and trading party
Verify that the fields disabled at each matching scope are all absent
Confirm that a document with an empty critical field cannot be approved or validated
Validate the merge behavior:
Create a document matching Global settings only → verify the Global result
Create a document matching Country settings → verify Country's disabled fields and critical marks are added to Global's
Create a document in a specific Organization → verify Organization's settings are added on top
Create a document from a specific Trading Party → verify all four scopes are combined
Disable a field at one scope and mark the same field critical at another → verify the field is removed and never enforced
Test with different user roles:
Admins should see all four tabs and be able to edit each one
Managers should see the Organization and Trading Party tabs, and not Country or Global
A custom role should see the tabs it was granted, with Country and Global view only and their controls greyed out
Users with the Reviewer, Validator or Reviewer and Validator role should see only the resulting field visibility and critical markers on documents, not the customization settings
Supported Configurations and Options
Configuration | Description | Scope Levels | Field-level | Section-level |
Global Baseline | Default field visibility and critical marks for all documents | 1 (Global) | Yes | Yes |
Country Configuration | Region-specific customizations | 1 (Country) | Yes | Yes |
Multi-org Customization | Organization-specific rules | 1+ (Organization) | Yes | Yes |
Trading Party Rules | Partner-specific field requirements | 1 (Trading Party) | Yes | Yes |
Critical Marking | Requires an enabled field to carry a value before approval or validation | All scopes | Yes | No (per field) |
Mandatory Fields | Trading party name fields cannot be disabled; Primary/Secondary Party section toggles stay locked | All scopes | Yes (locked) | Yes (locked) |
Merge Model | Every matching scope is combined; disabled removed first, then critical applied | All scopes | Yes | Yes |
Other Technical Specifications
Aspect | Details |
Scope Count | 4 levels (Global, Country, Organization, Trading Party) |
Resolution Model | Additive merge across all matching scopes; no priority order and no first match |
Merge Order | 1. Remove fields disabled at any scope. 2. Apply critical marks from any scope to the remaining fields |
Section-level Control | Show or hide entire form sections |
Field-level Control | Show or hide individual extraction fields; mark enabled fields as Critical |
Mandatory Fields | Trading party name fields in Primary Party and Secondary Party (cannot be disabled) |
Critical Default | Nothing is critical by default; marks come only from a saved customization |
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 |
Destination Format | Critical marks are not shown or carried in the destination format output |
Non-destructive | Disabling and marking never change stored data or extraction behavior |
Multi-org Selection | Organization scope supports multiple organizations in a single configuration |
Duplicate Prevention | Blocked per Document Type + Scope + Target combination |
Undo/Revert | Previous versions retained; can revert to a prior customization state |
Applied At | Continuously, using the current configuration; existing documents are affected, approved documents are not re-evaluated |
Audit Trail | All customization changes logged with user, timestamp, scope, and before/after state |
Notes
Disabled beats critical. If a field is disabled at one scope and marked critical at another, the field is removed and never enforced. Disabled fields are subtracted before critical marks are applied.
Nothing un-marks. No scope can re-enable a field another scope disabled, or clear a critical mark another scope set. To stop a field being enforced, remove the mark at the scope that set it.
Primary/Secondary Party protection: the sections themselves cannot be disabled, because the trading party name fields inside them are mandatory. The remaining fields in those sections can be disabled like any other.
Multi-org field conflicts: if two organizations have conflicting customizations for the same field, each document is processed according to its assigned organization.
Country matching sensitivity: country assignment must match exactly; mismatches mean the Country scope simply does not contribute to the merge.
Large-scale changes: because every scope is additive, disabling or marking a field at Global affects every document; plan Global changes carefully in production.
Existing documents are affected. Customizations apply at all times, not only at extraction, so a change can block approval on documents that are already in the queue. Approved documents are the exception and keep their status, empty critical fields included.
Empty tables never block. A critical field in a table is only checked against rows that exist; a table with no extracted rows does not stop approval.
No bulk revert: individual scope customizations must be reverted one at a time; bulk revert across all scopes is not available.
Limited conditional logic: customizations cannot be conditional on field values (for example, "require Tax ID only if Country is EU"); rules are static per scope. To block approval on a condition, use a custom validation in Instruction Builds instead.