Designing form templates

A form template defines what a Workspace collects. It's the data collection instrument for a specific workflow — onboarding a new customer, running a periodic review, gathering evidence for an enhanced due diligence check. Designing one well means being clear about the workflow it serves before thinking about the fields it contains.

What form templates are for

Form templates are designed for structured data collection tied to a specific process. The key word is process — a form exists inside a workspace, and a workspace represents a piece of work with a beginning, a middle, and an end.

This is different from the entity profile. The entity holds what you know about a customer as a standing record. A form captures what you need to collect from them — or about them — at a specific point in time, for a specific purpose. A completed form is a record of that interaction: what was asked, what was answered, and when.

Forms, custom fields, and notes

Before designing a form template, it helps to be clear about which tool is doing what.

Custom fields live on the entity and hold stable, structured attributes about the customer — things like their membership category, their source-of-wealth classification, or an internal reference number. Custom fields are always there on the entity profile, regardless of any specific workflow.

Form templates collect data in the context of a workflow. The data collected may update custom fields on the entity, or it may simply live in the form submission as evidence that something was completed. Some of what a form collects is never stored on the entity at all — a customer declaration, supporting documents, or a third-party response.

Notes are for unstructured, one-off observations. If you're writing free text that only applies to a particular moment or conversation, a note is the right place for it — not a form field.

Deciding what the form needs

Before you start building, answer these questions about the workflow the form is serving.

Who completes this form? The form design changes significantly depending on whether it's completed by a customer who has never used BNDRY before, by a staff member on behalf of a customer, or by an external collaborator. A customer-facing form needs to be self-explanatory and low friction. A staff-facing form can assume more context and use different language.

What does this form need to collect that isn't already on the entity? If a piece of information already lives on the entity profile as a standard field or custom field, consider excluding it rather than asking the customer to provide it again. A form that asks customers for information you already have creates friction and erodes trust.

What does the completed form need to produce? A submitted form is primarily a record: evidence that a customer has been through a process, confirmed a declaration, or provided supporting documents. Think about who will review the submission and what they need to see — a staff member closing out a due diligence check, a manager reviewing an onboarding, an auditor looking at what was collected and when. That audience shapes what the form needs to capture.

Is this one workflow or several? Separate workflows should have separate templates, even if they collect similar data. An individual onboarding form and a company onboarding form serve different processes, and conflating them produces a form that's awkward for both. Templates are cheap to create and easier to maintain when they have a single, clear purpose.

Thinking about structure and flow

Multi-step forms work best when each step has a clear theme. The person completing the form should be able to understand what a step is asking for without reading every question first.

Start with the steps that are easiest to complete — basic contact details, confirmations — and move toward the more demanding sections (documents, declarations, financial information) as the person moves through the form. A customer who has already completed two steps is more likely to finish a harder third step than one who encounters it first.

Think carefully about what changes based on the customer's situation. A form that asks a sole trader the same questions as a large corporate entity is a form with a design problem. Conditional sections — content that only appears when it's relevant — reduce friction and make the form feel purpose-built rather than generic.

Where possible, surface information you already have. If the entity has a name and date of birth on file, showing those to the customer for confirmation is better than asking them to type them again.

Templates and in-flight workspaces

Updating a form template doesn't change workspaces that are already open. An in-progress workspace continues to use the template version it was created with. New workspaces created after the update use the new template.

This means you can iterate on a template without disrupting active work — but it also means that if you need to collect something new from customers who already have open workspaces, you'll need a plan for how to handle that transition.

Next step

Once you're clear on the workflow, who completes it, and what it needs to produce, use Edit your forms and custom fields with help from AI to build the template and paste it into Settings.