Overview

The Form block is the primary way to capture validated, structured input in UnifyApps. It supports 27 field types — text, numbers, dates, dropdowns, file uploads, and more — arranged in one of three source modes: Manual, Object, or Schema. Every new Form arrives pre-assembled with a title header, a footer containing Reset and Submit buttons already wired to the form, and an On Submit success notification you can replace with your own actions.

Note: When to use the Form block

• Collect user input that must be validated before anything runs, such as sign-ups, settings and requests.

• Create or update records of a platform object without wiring individual inputs by hand: use the Object source.

• Render a form whose shape is decided at runtime by data (an API response, a variable): use the Schema source.

• For a single free-standing input tied to no submission flow, prefer a standalone input block instead.

The Three Source Modes

The Source toggle is the block's spine — it decides where fields come from and which inspector properties are shown.

A freshly dropped Form starts in Manual mode with a starter field set. Switching source modes changes which inspector properties appear — Select Object / Action / Record ID, JSON Schema / UI Schema / Default Form Data, and so on.

Manual Source

Build the field list yourself from 27 available types. Fields can also be mapped from bound data — a collection or variable — so the field set changes when your data changes. Use this mode for any custom form that doesn't map directly to a platform object.

Object Source

Select a platform Object, an action (Create or Update), and (for Update) a Record ID. The Form generates its fields from the object's schema automatically. Object-sourced forms pre-populate on Update, validate against the object's constraints, and submit directly to create or update records — no manual wiring needed.

When Source is set to Object, the inspector shows:

Schema Source

Bind a JSON Schema (and optionally a UI Schema and Default Form Data) to drive the form's shape at runtime. The form re-renders whenever the bound schema changes. Use this for forms whose structure is determined by data coming from an API or a variable. The setFormData method is only available in Schema mode.

When Source is set to Schema, the inspector shows:

Content Properties

Fields

Slots

The form has two fixed drop-zones — a header and a footer. A new Form ships with a header containing the form title and a footer containing Reset and Submit buttons. Every individual field also has its own header/footer slots for placing helper content around each field.

Tip: Relabeling, restyling, or deleting the default footer buttons only changes those specific blocks — the form's submitForm and resetForm methods keep working independently, since any button (or other action) can call a method by targeting the form directly.

Interactions

Permissions

Appearance

The Appearance panel controls how the whole form looks and behaves as a block — field layout, label/description styling, disabled and read-only states, and overall block sizing. These settings apply form-wide; each individual field also has its own Appearance settings.

Note: There is no grid or column-count option. The form lays fields out in a single column, or places each field's label beside its input with Row. For a multi-column look, set each field's Width (as a percentage of the form row, under the field's Appearance) so two or more fields share a row — e.g. 50% on two adjacent fields.

Exposed State

Read these values from anywhere on the page. Replace form1 with your form's block ID. This is the reference table for form state; Form Validation, Methods & Events links here.

Behavior & Gotchas

Warning: Disabling or locking the whole form overrides every field's own setting. When Disabled is on, every field is turned off no matter what a field's own Disabled setting says, and pressing Submit fails the action (its On Error branch runs) and nothing is submitted. When Read only is on, the form cannot be submitted and edits are not saved.

Warning: Auto Focus does nothing while you're building. The Auto Focus toggle only takes effect in the live app and in preview. While editing in the builder it is deliberately ignored so it doesn't steal focus from the inspector.

Note: Custom CSS and HTML Attributes only appear once already applied. The Custom CSS and HTML Attributes controls are hidden from the Appearance panel until the form already has them on it. If you don't see them, this form has none applied yet.

Warning: Switching field-description style clears the previous style's settings. Field Description has three styles — Inline, Dashed, and Icon — and only the selected style's extra settings are kept. Switch away and those settings are discarded; switching back starts them fresh at defaults.

Step-by-Step Examples

Lay Fields Out in Two Columns

1. Leave Layout = column so labels sit above inputs.

2. Open each field's own Appearance and set its Width to 50%.

3. Two adjacent fields at 50% now share one row. Repeat for further pairs.

Put Labels Beside Their Inputs

1. Set Layout = row in the form's Appearance panel.

2. Every field now renders its label to the left of its input instead of above it.

Disable the Form Until It's Ready

1. In Appearance, set Disabled to a condition — e.g. a binding that is true until a record has loaded.

2. While the condition is true the whole form is greyed out and cannot be submitted.

3. When the condition turns false the form becomes editable.

Build a Dynamic Form from an API Response

1. Set Source = Schema.

2. Bind JSON Schema to your API response field that contains the schema, e.g. {{ myApi.data.formSchema }}.

3. Optionally bind Default Form Data to pre-populate values.

4. The form re-renders whenever the bound schema changes.

Related Pages