Form Overview & Appearance

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 blockCollect user input that must be validated before anything runs — sign-ups, settings, 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.

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.

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.

Content Sources Deep Dive

Object Source Properties

When Source is set to Object, the inspector shows additional properties:

Schema Source Properties

When Source is set to Schema, the inspector shows:

Exposed State

Read these values from anywhere on the page using {{ formId.* }}:

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 does nothing. 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.

Frequently Asked Questions

Can I use a Form block without the default Submit button?

Yes. The default Submit button in the footer slot is just a regular button pre-wired to the form's submitForm method. You can delete it and place your own button anywhere on the page — call submitForm on the form block from any button or interaction. The form's submit behavior is independent of the default footer buttons.

How do I pre-populate a form when editing an existing record?

Set the form's Source to Object, set Action to Update, and bind Record ID to the record's identifier (e.g. {{ myTable.selectedRow.id }}). The form auto-populates all fields from that record. For Manual source forms, bind each field's Default Value to the corresponding record field.

Why does my form reset when I hide and re-show it?

The Reset form when hidden property is on by default (Inspector → Content → Interactions). When the form's visibility condition turns false or the form unmounts, it clears all user input. Turn this off in Interactions if you want to preserve the user's entries across hide/show cycles.

What is the difference between Disabled and Read Only on a form?

Disabled greys out every field and prevents submission entirely — calling submitForm while the form is disabled does nothing. Read Only allows the user to see all values but not edit them, and also blocks submission. Use Disabled when the form is not yet ready (e.g. data still loading); use Read Only to display existing values the user should not change.

Can I build a multi-step wizard with a Form block?

Yes, with a few techniques. You can show different groups of fields on each step by using field Visibility conditions tied to a step variable, or by placing fields across multiple Form blocks on separate pages/tabs and collecting data into variables. Call validateForm at each step transition to check the visible fields before advancing. The Form does not have built-in wizard steps, but these patterns achieve the same result.

Related Pages