Form builder

What this accomplishes

Build forms in Canvas — field types, validation, and local data binding.

The form builder is a visual builder for forms in the Canvas. The form builder lets the user add a form block to a page; the form block is a set of fields, a submit button, and a success / error state. The form’s data is stored in the project’s data block; the form is published with the app.

This page is the form builder. The data block (which the form writes to) is in local data; the canvas builder (which the form lives in) is in canvas builder.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Canvas open.
• A connected model and permission to write project files when the task changes the app.

The field palette

The field palette is a CoW panel in the inspector when the user selects a form block. The palette shows the field types the user can add to the form. The field types are:

• Text — a single-line text input.
• Email — a single-line text input with email validation.
• Phone — a single-line text input with phone validation.
• Number — a numeric input.
• Date — a date picker.
• Time — a time picker.
• Single-select — a dropdown.
• Multi-select — a multi-select.
• Checkbox — a single checkbox.
• File upload — a file input.
• Signature — a signature pad.
• Hidden — a hidden input (the value is set by the form’s submit action).

The user drags a field from the palette to the field list. The field appears in the form preview.

The field types and the per-field properties

Each field type has a set of properties the user can configure. The common properties are:

• Label — the field’s label (e.g. “Email address”).
• Placeholder — the field’s placeholder (e.g. “you@example.com”).
• Required — whether the field is required. The form does not submit if a required field is empty.
• Default value — the field’s default value (the value the field has when the form loads).
• Help text — the field’s help text (shown below the field).
• Validation — the field’s validation rules. The validation can be a regex, a min, a max, or a custom message.

The field-type-specific properties are:

• Text, email, phone — the maximum length, the minimum length, the regex pattern.
• Number — the minimum value, the maximum value, the step.
• Date, time — the minimum date, the maximum date, the format.
• Single-select, multi-select — the options (a list of label-value pairs).
• Checkbox — the label for the checked state, the label for the unchecked state.
• File upload — the allowed file types, the maximum file size, the maximum number of files.
• Signature — the signature’s width, the signature’s height.
• Hidden — the value (the value is set by the form’s submit action; the value is not editable by the user).

The submit action

The form’s submit action is what happens when the user clicks the submit button. The submit action can be:

• Post to the project’s data block — the form’s data is posted to the data block. The data block stores the submission in a local SQLite database.
• Post to an external endpoint — the form’s data is posted to an external endpoint. The user configures the endpoint URL, the HTTP method, the authentication, the headers.
• Send an email — the form’s data is sent as an email to a configured address. The user configures the email subject, the email body, the email recipients.
• Trigger a workflow — the form’s data is passed to a workflow as the workflow’s input. The user picks the workflow from the workflow list.

The default is post to the project’s data block. The user can configure a different submit action in the inspector.

The success state

The form’s success state is what the user sees when the form submits successfully. The success state can be:

• A thank-you message — a static text message the user sees after the form submits. The user configures the message in the inspector.
• A redirect to a URL — the form redirects the user to a URL. The user configures the URL in the inspector.
• A download — the form triggers a download. The user configures the download URL in the inspector.

The default is a thank-you message. The user can configure a different success state in the inspector.

The error state

The form’s error state is what the user sees when the form submits with an error (e.g. a network error, a validation error). The error state can be:

• A generic error message — a static text message the user sees when the form submits with an error.
• A custom error message — the user configures the message in the inspector.
• A redirect to a URL — the form redirects the user to a URL when the form submits with an error.

The default is a generic error message. The user can configure a different error state in the inspector.

The anti-spam

The form has anti-spam. The anti-spam includes:

• A hidden honeypot field — a hidden field that is invisible to the user. A bot that fills in all fields will fill in the honeypot. The form rejects the submission if the honeypot is filled in.
• A time-to-submit check — the form rejects the submission if it arrives in under three seconds (a bot fills in the form in milliseconds; a human takes longer).
• An optional CAPTCHA — the form has an optional CAPTCHA. The user can enable the CAPTCHA for high-traffic forms. The CAPTCHA is the standard hCaptcha.

The anti-spam is on by default. The user can disable the anti-spam in the inspector; the user can also enable the optional CAPTCHA.

The form preview

The form has a preview. The preview is in the inspector when the user selects the form block. The preview shows the form as the user will see it; the user can fill in the form; the user can submit the form (the submit runs against a test version of the submit action; the form does not write to the live data block).

The preview is a CoW panel. The user can close the preview without losing the configuration; the user can reopen the preview from the inspector.

The preview is per-form. The preview updates as the user changes the form’s configuration.

What the form builder does not cover

The form builder does not cover:

• Conditional fields — the user cannot show or hide a field based on the value of another field. The user can use a custom component for conditional fields; the user can also use a third-party tool for conditional forms.
• Multi-step forms — the form is a single step. The user can use a custom component for multi-step forms; the user can also use a third-party tool for multi-step forms.
• File storage — the form’s file uploads are stored in the project’s asset library. The user can configure the storage to be a third-party service (e.g. S3) in Settings.

The form builder focuses on the common form shapes (single-step, single-page). The less common cases are covered by the user’s existing tools.

What success looks like

The form builder is the right shape for the user to add a form to the no-code app. The user adds a form block; the user adds fields; the user configures the submit action; the user publishes the app.

The field palette is the entry point. The user drags a field from the palette to the form; the user configures the field’s properties in the inspector.

The submit action is the right shape for the user to decide where the form’s data goes. The default is the project’s data block; the user can also post to an external endpoint, send an email, or trigger a workflow.

The anti-spam is the right shape for the user to prevent bots from submitting the form. The honeypot and the time-to-submit check are on by default; the optional CAPTCHA is for high-traffic forms.

Common failures and recovery

• Confirm Canvas is editing the intended project and page.
• Check the selected breakpoint, project permissions and model connection.
• Reopen the last known-good project state before applying the change again.

Related next action

Return to the Canvas overview to choose the next part of the project.