Custom Fields

Custom fields are the primary way to capture structured data alongside documents in Docwize. Beyond the standard metadata Docwize records automatically, custom fields let administrators define what additional information the system captures — invoice amounts, supplier names, approval statuses, contract dates, risk scores, or any other data relevant to the organisation's documents.

Custom fields are foundational to most of Docwize's configuration. Records, workflows, the Query Builder, Chart Builder, and Interface Builder all depend on custom fields being defined first. Plan custom field structure before configuring those areas.

What custom fields are used for

Once defined, custom fields appear wherever structured data needs to be captured or displayed:

Area	How custom fields are used
Records	Custom fields populate the data-entry forms users complete when submitting documents
Workflows	Custom fields can be referenced in workflow logic; AI extraction can populate them automatically
Dataviews	Custom fields provide the columns users see when browsing documents in Explorer
Query Builder	Custom fields form the data layer that virtual views are built from
Chart Builder and Interface Builder	Charts and dashboards are built from Query Builder datasources, which in turn draw on custom fields

Custom field templates

Custom fields are defined and managed through templates. A template groups one or more custom field entries — for example, an invoice template might contain fields for Supplier, Amount, Currency, and Approval Status.

Templates are created and managed via New → Custom Fields. Administrators with the Manage Document Custom Fields permission can create, edit, and deactivate templates.

Once a template has been used to capture data, changes to field types or structure may affect existing records. Plan template structure before putting fields into use where possible.

For full instructions, see Create New Custom Field Template.

Field relationship types

Custom fields can relate to documents in different ways depending on how the field is configured. The relationship type determines how the data is stored, displayed, and linked.

Type	What it means
One-to-one	A field that holds a single value unique to that document — e.g. a PO number or a reference date
One-to-many	A field that holds multiple values on a single document — e.g. a list of reviewers
Many-to-many	A field whose values are shared across multiple documents — e.g. a shared asset register or risk register
Custom field-to-custom field	A field whose values are linked to the values of another custom field

For a full explanation with diagrams, see Custom Field Relationships.

Lookup lists

Lookup lists define the allowed values for dropdown and selection fields. When a custom field requires users to pick from a fixed set of options — document types, project codes, yes/no/unsure — a lookup list provides those options.

Lookup lists are built using the Lookup List Builder, located in New → Custom Fields. A lookup list draws on an existing custom field template and, where applicable, a virtual view.

Lookup lists should be populated before the dropdown fields that reference them are put into use. If a lookup list is empty or missing when a field goes live, users will see an empty dropdown.

For full instructions, see Lookup Lists.

Registers

Registers provide a way to view and edit many-to-many custom field data directly — for example, an employee register, an asset register, or a risk register. Register contents can be updated without going through individual documents.

Registers are accessed via New → Custom Fields. For full instructions, see Manage Registers.

Lists

The Manage Lists section allows administrators to view, add, and edit list data within the database. It is also located in New → Custom Fields.

For full instructions, see Manage Lists.

Default upload extraction

The Default Upload Extraction configuration is also accessible via New → Custom Fields and Configurations. It controls which extraction rules apply automatically when documents are uploaded — extracted values are written into the custom fields defined in your templates. Documentation for this area is pending.

Before configuring custom fields

Plan what data you need to capture before creating fields. Field types and relationship structures can be changed after data has been entered, but this may affect existing records. Plan ahead where possible to reduce rework.

Agree on field names before configuring records and workflows. Records and workflows reference custom fields by name. Renaming a field after records or workflows have been built around it may require updating those configurations. [NEEDS SME CONFIRMATION: whether renaming a custom field propagates automatically to records and workflows that reference it, or whether those references break]

Populate lookup lists before fields go live. Users completing a record or workflow step that includes a dropdown field will see an empty list if the lookup list has not been populated.

Deactivate rather than delete unused templates. Deleting a template that has existing data associated with it may cause data loss or display errors. [NEEDS SME CONFIRMATION: exact behaviour when a template with existing data is deleted]

Coordinate with anyone configuring records, workflows, or Query Builder. Changes to custom field structure affect everything downstream. Treat custom fields as shared infrastructure.

Related configuration

• Custom Field Relationships — how field types relate to documents and each other
• Create New Custom Field Template — creating and managing field templates
• Lookup Lists — defining allowed values for dropdown fields
• Manage Registers — viewing and editing many-to-many field data
• Manage Lists — managing list data in the database
• Records — data-entry forms that use custom fields
• Workflows — workflow templates that reference or extract custom field data
• Query Builder — virtual views built from custom field data