Forms

A form in BNDRY is a structured questionnaire that an end user fills out — typically a customer completing onboarding, KYC, a periodic review, or a remediation step. Each form is an instance created from a form template, carries the responses captured against that instance, and has its own state and audit trail. Forms are the primary way BNDRY collects structured data from people outside the organisation.

Why forms exist

Most regulated data collection has the same shape: a known list of questions, predictable validation rules, a need for an audit trail, and an obligation to give the end user a clean experience. Forms exist so that BNDRY can answer that shape once, well, and reuse it across onboarding, KYC, reviews, and any other structured collection the organisation runs.

Separating the form definition from the form instance is what makes this work in practice. A definition is authored once and changed deliberately; instances are created from it and accumulate responses without altering the underlying schema. This means a reviewer can always tell which version of a question a particular respondent answered, and changes to the template don't retroactively rewrite history.

Key properties and sub-types

A form instance carries the fields needed to render it, accept responses, and trace its lifecycle:

• Form definition — the immutable reference to the template that produced this form. The definition supplies the FormKit schema; the instance supplies the answers.
• FormKit schema — the JSON structure that drives the multi-step form UI. It is derived from the form definition and surfaced on the instance for rendering.
• Response — the JSON object containing the user's answers. This is the field that grows as the user works through the form.
• Display name — an optional human-readable label, distinct from the underlying schema title.
• Workspaces — the workspaces this form belongs to. A form can exist standalone, but inside a workspace it inherits the workspace's access scope and audit context.
• Automations — references to any platform automations associated with the form, used to drive downstream workflows on submission.

The schema language is FormKit JSON. Form definitions can range from a single page to multi-step workflows with conditional fields and computed displays. The schema is powerful, and it is also fragile: a malformed schema will not fail gracefully — the form crashes rather than just the broken field. BNDRY has a dedicated tool for authoring and validating these schemas safely, and templates should always be tested in the same context the user will see (portal, embedded, dark mode) before going live.

How forms relate

A form is created from a form template and lives inside a workspace. The workspace provides the surrounding context — who the work is for, what state the broader case is in, which other forms and files belong with it.

End users complete forms through the portal, usually arriving via a workspace magic link. Files uploaded against a form during completion are stored against the form and listed at the workspace level too.