Field Builder
The Field Builder block provides a drag-and-drop interface that lets end users construct custom form schemas at runtime — without any developer involvement. Admins or power users define which fields exist, what type they are, and what options they offer, and those definitions are saved back to your data source for later retrieval.
Overview
Place a FieldBuilder block wherever you need end users — not developers — to define the shape of a form. Common scenarios include CRM custom fields, no-code survey builders, and intake form configurators where different teams need different fields without a new deployment. The block renders a builder UI (add field, drag to reorder, configure each field) and exposes the resulting schema as a bindable output variable you can save to a data source.
Note: The Field Builder is for configuring a form's schema — it is not a data-capture form itself. Pair it with a Form block (Source = Schema) to let users both design and fill forms: the Field Builder produces the schema, the Form block renders it.
Properties
Content Properties
| Property | Type | Default | Description |
schema | array | [] | The current field schema. Each item is a field definition object (see Schema Item Properties below). Bind to a data source to load a saved schema; the block will render it and allow the user to modify it. |
editable | boolean | true | When true, the builder UI (Add Field button, drag handles, field configurator) is shown. When false, the schema is rendered as a read-only summary list — useful for previewing a saved configuration. |
maxFields | number | — | Maximum number of fields a user can add. The Add Field button is disabled once this limit is reached. Leave unset for unlimited fields. |
allowedTypes | array of strings | All types | Restrict which field types appear in the Add Field picker. Accepts any subset of text, number, date, dropdown, checkbox, file. When empty or unset, all types are available. |
outputVariable | string | — | Name of the page variable to write the current schema into whenever it changes. Reference this variable to read the live schema anywhere on the page — e.g. bind a Form block's JSON Schema to {{ myVariable.value }}. |
Event Properties
| Property | Type | Description |
onChange | event handler | Fires every time the user adds, removes, reorders, or reconfigures a field. The event payload contains schema — the full updated field array. Use this to trigger a data source save action. |
Schema Item Properties
Each element in the schema array represents one field. The Field Builder reads and writes objects with the following shape:
| Key | Type | Required | Description |
id | string | required (required) | Unique identifier for the field within the schema. Used as the key in the form's data object when the schema drives a Form block. Auto-generated if the user does not set one explicitly. |
label | string | required (required) | Human-readable label displayed above the field in the rendered form. |
type | text | number | date | dropdown | checkbox | file | required (required) | The field's input type. Determines which renderer the Form block uses when this schema drives it. |
required | boolean | optional (optional) | When true, the field is marked required and the Form block enforces a non-empty value before submission. |
placeholder | string | optional (optional) | Placeholder text shown inside the field when empty. Applies to text, number, and date types. |
options | array | optional (optional) | For dropdown type only. Array of { label, value } pairs the user configures in the field's options editor. Ignored for other types. |
Tip: When saving schemas to a data source and loading them later, ensure the id values on each field do not change between saves. If IDs change, any data previously captured under the old ID will not map to the new field in the rendered form.
Binding and Data Flow
The typical Field Builder data flow has three stages: load, edit, and save.
Load — bind the schema from your data source: Set the schema property to a binding expression that resolves to a previously saved schema array — e.g.
{{ loadFormConfig.data.schema }}. When the data source loads, the Field Builder renders the saved fields.Edit — user modifies the schema: The user adds, removes, reorders, or reconfigures fields. Each change fires the onChange event with the updated schema array as the event payload (
{{ event.schema }}).Save — write the schema back to your data source: In the onChange handler, add a Trigger Data Source action that calls your save endpoint with
{{ event.schema }}as the body payload. The schema is now persisted for the next load.
Use Cases
CRM Custom Fields
Allow CRM administrators to define extra fields (industry, contract tier, referral source) for contact or deal records without a developer deploy. The Field Builder stores the schema; the main CRM form loads it via the Form block's Schema source.
Survey Builder
Build an internal survey tool where HR or ops teams can compose their own question sets. Restrict allowedTypes to ["text", "dropdown", "checkbox"] to keep options relevant to survey-style questions, and set maxFields to 20 to prevent excessively long surveys.
Dynamic Intake Forms
Different departments need different intake forms — IT requests, facilities requests, HR requests. Each department configures its own schema via the Field Builder, stored as a separate record. Employees see the correct form for their department, driven by a single Form block bound to the relevant schema.
Example: Admin Form Configurator
Wiring Field Builder → Form block → Save action
// 1. FieldBuilder: schema bound to loaded config schema = {{ loadFormConfig.data.schema }} outputVariable = "currentSchema" onChange → Trigger: saveFormConfig (body: { schema: {{ event.schema }} }) // 2. Form block (on the same or a separate page): source = json_schema jsonSchema = {{ currentSchema.value }} // 3. Rendering the live schema in a preview panel: // Bind a Form block's jsonSchema to currentSchema.value — updates // immediately as the user edits fields in the Field Builder. // 4. Limiting to survey-relevant types: allowedTypes = ["text", "dropdown", "checkbox"] maxFields = 15
Warning: Deleting or renaming a field in the Field Builder does not migrate data that was already captured under the old field ID. Plan field IDs carefully, and consider soft-deletion (hiding a field) rather than hard removal when data has already been collected.
Appearance Properties
| Property | Type | Default | Description |
visibility | condition | — | Show or hide the entire block based on a condition. Use to restrict the builder UI to admin roles only. |
disabled | condition | — | Disable all editing controls while keeping the schema visible. Useful during a save operation to prevent concurrent edits. |
styles | style set | — | Width, height, padding, and overflow for the Field Builder container. |
Frequently Asked Questions
Can users reorder fields after adding them?
Yes. When editable is true, each field row has a drag handle on the left. Users can drag fields up or down to reorder them. The order in the schema array reflects the display order in the rendered Form block. The onChange event fires after each reorder.
How do I show a live preview of the form as the user builds it?
Set the Field Builder's outputVariable to a page variable name (e.g. schemaPreview). Place a Form block elsewhere on the page, set its Source to Schema, and bind its JSON Schema to {{ schemaPreview.value }}. Every time the user changes a field, the output variable updates and the Form block re-renders, giving an instant live preview.
What happens if I bind a schema that contains a field type not in allowedTypes?
The field is loaded and displayed correctly regardless of allowedTypes — that property only restricts what types can be added via the Add Field picker. Existing fields of any type are always shown. If you want to prevent displaying disallowed types, filter the schema before binding it to the block.