Document forms

Document Forms turn document creation and editing into a guided, structured experience. Instead of a single rich-text editor or file preview, authors see a layout of sections and fields tailored to the document type — metadata, configurable properties, risk summaries, linked documents, and more.

Purpose

Document Forms exist to visualize and collect document properties in a structured way.

They help when:

• Documents need consistent metadata (owner, classification, review date, linked assets, etc.)
• Risk-related documents should visualize initial, current, and target risk at a glance
• Related documents should be visible and editable inline without leaving the form
• Authors should follow a fixed layout rather than a blank page

A Document Form does not replace document types or document properties. It is just a different view layout that a document type can opt into. The underlying data still lives in the document properties, linked items, risk readings, etc.).

Note: Document Forms are different from Request Forms . Request Forms are public or internal submission workflows that trigger workflows. Document Forms are layouts for viewing and editing documents of a given type.

How it fits together

Key components

A Document Form is built from resizable sections containing fields. Fields fall into three categories.

1. Configurable document properties

These are workspace-defined Document Properties that can be placed on the form. Each property has a reply type that controls how it is visualized in the UI:

Properties support:

• Title and description/label (help text)
• Multi-language translations for title and label (when translations are enabled)
• Mandatory flag (enforced in combination with document-type configuration)

2. Widgets

Widgets show richer document data or specialized editors:

Linked document widget properties

Linked document widgets can be configured per field:

• **Document type to show **— defines which linked document type is shown (the grouped widget shows all linked document types)
• Show/edit document properties — choose which properties of the linked document type appear inline, and whether each is show-only or editable. Only properties assigned to the linked document type (mandatory or optional) are available for inline display.
• Show metadata — optional display of creation date, modification date, process status, and initial/current/target risk on linked items.

3. Document metadata

Read-only or editable document metadata:

Sections and layout

Document Forms use a 12-column GridStack grid. Each form consists of one or more sections, each with:

• Position and size — x, y, w, h grid coordinates
• Title — section heading shown to users
• Fields — ordered list of metadata, properties, and widgets

In the form editor, sections can be:

• Added and removed
• Dragged and resized on the grid
• Given translated titles (see below)

When viewing or editing a document, sections render as collapsible cards. The grid auto-resizes to fit content.

Custom translations

Multi-language support is available at two levels.

Section titles

In the form editor, each section title can enable translations. When enabled, you provide a title per enabled workspace language. Stored as title_translated (a language-keyed map). At runtime, the UI picks the title for the user’s active language, with fallbacks to English and the base title.

Document property labels

Document Properties can enable translations for:

• Title — field label on the form
• Label/description — help text shown beside the field

Property translations are configured in Workspace Settings → Document Properties, not in the form editor itself. The form references the property definition; translated labels resolve at render time based on the user’s language.

Configuring Document Forms (form editor)

Document Forms are managed under Workspace Settings → Document Form.

Creating or editing a form

1. Set a title — the name shown when assigning the form to document types.
2. Add sections — new forms start with two empty sections; more can be added.
3. Design the layout in the form designer:

• Left palette — searchable list of available components (Metadata, Property, Widget)
• Right canvas — GridStack sections where components are dropped

4. Drop components from the palette into a section, or reorder fields by dragging within/between sections.
5. Configure fields where needed:

• Guidance text — edit the guidance content
• Linked Docs (Specific) — pick the document type; configure inline property/metadata visibility
• Linked Docs (Grouped) — configure metadata visibility

6. Edit section titles — click the pencil on a section; optionally enable per-language translations.
7. Save — layout is stored.

Palette rules

• Most components can appear only once per form (and are therefore hidden from the left palette when used).
• Horizontal Rule and Linked Docs (Specific) may be added multiple times (e.g. several linked-doc blocks for different types).
• Document Properties from the workspace appear in the palette under Property type. All workspace properties are available; you choose which to include on each form.

Configurable Document Properties

Document Properties are defined separately under Workspace Settings → Document Properties. They are the building blocks that forms can display.

Defining a property

When adding or editing a property, you configure:

Reply-type specifics

• Text (1) — optional default text value
• Single-select (2) / Multi-select (3) — list of options
• Link picker (4) — one or more document types users may link to (e.g. Employee, Product, Control)
• Date (5) — date field

Like forms, properties can be workspace custom or Brainframe defaults (importable into the workspace).

Relationship to Document Forms

1. Create properties in Document Properties settings.
2. Drag properties from the form editor palette into sections.
3. At runtime, the form renders each property with the correct input control and reads/writes the document’s property bag.

A property does not have to be on a form to exist on a document type — see document-type configuration below. Conversely, placing a property on a form does not by itself make it mandatory; that is controlled on the document type.

Configuring on Document Types

Document Forms are assigned per document type under Workspace Settings → Document Types.

Document view vs Form view

Each document type has a View setting:

When Form view is selected:

1. Choose Select view — pick which Document Form to use (required).
2. Save the document type.

Documents of that type then load the form layout from auth/getDocumentForm (cached workspace-wide). If a document already has embedded documentFormData, that snapshot can be used directly.

Mandatory and optional document properties

On the same document type dialog, separate from the form assignment:

• Mandatory document properties — must be filled in; enforced when creating/editing documents of this type
• Optional document properties — available but not required

These lists:

• Control which properties are part of the document type’s data model
• Feed validation and default property initialization
• Limit which properties can be shown inline on linked document widgets for that type

Important distinction:

A mandatory property should typically appear on the form so authors can complete it. An optional property can be omitted from the form but still exist on the document (e.g. filled later or only used in search/filter).

Summary

Together, these pieces let administrators define what data documents carry (properties + document type rules) and how authors interact with that data (form layout), without changing the underlying Brainframe document model.

Updated on: 09/06/2026