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 definition (also called a form template in the BNDRY settings UI), carries the responses captured against that schema, 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.
• State — the form's lifecycle position (see below).
• Etag and timestamps — used for optimistic concurrency and the standard create/update audit trail.

Forms move through a small set of states:

• Open — the form is accepting responses.
• Submitted — the respondent has finished and submitted.
• Expired — the form is closed and no longer accepting responses.

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 definition (the template) and lives, typically, 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. Standalone forms (not attached to a workspace) are also possible for narrower use cases.

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.

On submission, a form can trigger automations that pick up the responses and drive downstream work — risk assessments, screening, document generation, or any other workflow the organisation has configured.