Why do validation errors only appear after I click Submit?

This is intentional behavior. Validation is silent until the form is first submitted or validateForm is explicitly called. From that point on, errors update live as the user types. Resetting the form returns it to the silent pre-submit state. This avoids overwhelming users with errors before they've had a chance to fill the form.

My validity condition never triggers even when the field has a wrong value — why?

Validity rules are skipped for fields that are currently hidden (visibility condition is false) or disabled. Check that the field is visible and not disabled at the time of submission. A read-only field is different — its rules still run. Also confirm there are no contradictions between multiple rules on the same field.

How do I validate one field against another — for example, a password confirmation?

Add a Validity condition to the confirmation field that references the password field: use the condition builder with the rule {{ form1.data.confirmPassword }} equals {{ form1.data.password }}. Add an error message like "Passwords do not match." This rule is checked at submit and live on every change after the first submit.

If I call setFieldValue, will it fire On Change?

Yes — setFieldValue and setFieldsValue fire On Change like a user edit, for the field and for the form. Reset methods and bound default updates do not fire events. Avoid calling setFieldValue on a field from that same field's On Change handler, as this can create a loop.

Can I submit a form from a button outside the form block?

Yes. From any button's click event, add a Trigger Component Method action targeting the form block's ID, and choose the Submit method (submitForm). The form validates and submits exactly as if the built-in Submit button was pressed. The action fails (and chained actions don't run) if the form is invalid, disabled, or read-only.

Form Validation, Methods & Events- UnifyApps

How Validation Works

unify-applications-form-validation-methods-and-events-01-validity-rule-builder.png

A Form decides three things as the user fills it in: what counts as valid, what stays on screen, and what ends up in the submitted data. These are driven by three mechanisms that work together:

Each field's Validity conditions — custom rules its value must pass.
Each field's Visibility condition — whether it is shown at all.
Each field's access Permissions — whether a given user is allowed to see it.

Because a hidden or disallowed field is dropped from the data and skipped by validation, these three are tightly coupled.

Note: Validation is silent until the first submit, then live. No errors show while the user types, and leaving a field (blur) does not trigger a check. After the first submit (or a validateForm call), every change re-validates immediately and errors appear/clear live. Resetting the form returns it to the silent state.

Writing Validity Conditions

Every field's Validity conditions (Field details → Validation) hold custom rules the value must satisfy. This is the mechanism behind every check that has no dedicated property — conditional requirements, cross-field comparisons, password confirmation, and similar.

How Rules Work

A rule is conditions plus an error message. Conditions are assembled in a visual AND/OR condition builder; each rule carries its own error message shown under the field while the rule fails.
A field can carry several rules at once. Each rule is checked independently and shows its own message while it fails — more than one error can appear at the same time. All rules must pass for the field to be valid.
Rules can reference other fields. Use {{ form1.data.<fieldKey> }} in the builder to compare against any other field's current value.
Rules run at submit, and after the first submit they re-check live on every change.
Hidden or disabled fields are skipped — a rule on a hidden or disabled field never fires at submit.

Available Operators by Field Type

Field Family	Available Operators
Text family (Text, Email, Password, Pin Input, Rich Text, Code Editor, Single Select Dropdown, Radio Group)	Minimum Length, Maximum Length, Does Not Start With, Does Not End With, plus the base set
Text Area	Minimum Length, Maximum Length, plus the base set
Phone Number	Minimum Length, Maximum Length, plus the base set
Numeric fields (Number, Integer, Slider, Currency Input)	The base set
Date / Date Time	Is Before, Is On or Before, Is After, Is On or After, plus the base set
Time	Is Before, Is Equal To or Before, Is Equal To, Is After, Is Equal To or After, plus the base set
Checkbox (Boolean) / Switch	The base set
Multi Select Dropdown / Checkbox Group	The base set

The base set is: Equals to, Does not equal, Contains, Does not contain, In, Not in, Match regex, Does not match regex, Starts with, Ends with, Less than, Less than or equal to, Greater than, Greater than or equal to, Is present, Is not present.

Built-in Property Validation

Three field-level properties enforce themselves as validation errors at submit time, independently of anything in Validity conditions:

Property	When It Triggers
Max Length (text-family fields)	A value longer than the field's Max length blocks submit. Typing normally can't exceed the cap, so this mostly surfaces when a too-long value arrives via a bound default, `setFieldValue`, or mapped data.
Text Transform	A value that doesn't match the field's Text transform blocks submit. Typing already keeps the value in the transformed shape, so this mainly surfaces for values set another way.
Date Selection Limits	On Date and Date & Time fields, disable-past/future-dates restrictions are enforced as submit-time validation errors — not just as picker restrictions.

Controlling What's Shown

Field Visibility Conditions

Each field has a Visibility condition (Appearance → Visibility) that shows or hides it based on a condition. The condition can reference other fields ({{ form1.data.<fieldKey> }}) or any binding on the page.

Warning: When a visibility condition is false, the field is not just hidden from view — its value is removed from the form's data and from the submit payload, and its validity rules are skipped. When the condition becomes true again, the field returns filled from its default (not from the user's prior entry).

Per-Option Visibility

Inside choice fields (single-select, multi-select, radio, checkbox), each individual option can carry its own visibility condition. An option whose condition is false is not offered in the list while the field itself and other options stay visible.

Field-Level Access Permissions

Any field can carry an access-permission rule (Field details → Permissions). When the current user does not meet the rule:

Default behavior: The field is removed from the form entirely — not just greyed out. A removed field also drops out of the submitted data.
Read-only fallback: If the field's "when no permission" setting is set to read-only, it stays on screen but cannot be edited. A read-only field still submits its value.

Conditionally Required Fields

Make fields compulsory only when another field has a certain value. Two patterns (the step-by-step how-to, with a worked GST Number example, is in Form Validation and Visibility):

Pattern 1: Validity Condition (field stays visible)

Add a Validity condition on the dependent field (Field details → Validation).
Set the rule condition: {{ form1.data.controllingField }} is NOT equal to yes OR the field's value is present.
Set the error message: "This field is required when [condition]."
The field is always visible but blocks submission when empty and the controlling field is yes.

Pattern 2: Visibility + Required (field appears only when relevant)

Turn Is Optional off on the dependent field.
Set its Visibility condition (Appearance → Visibility) to: {{ form1.data.controllingField }} equals yes.
The field only appears — and only requires a value — when the controlling field is yes. When hidden, it sends no data and its required check is skipped.

Mapped Fields

In Manual source mode, fields can be mapped from bound data — a collection, an API response, or a variable — so the field set changes dynamically when the data changes.

How Mapping Works

In Content → Fields, set the Manual / Mapped toggle at the top of the Fields editor to Mapped. This toggle is separate from the form's Source control (keep Source on Manual), and it replaces the hand-built field list for the whole form.
Bind Data to an array of field definitions (a collection, an API response, or a variable).
Pick the Field ID, Field Label and Field Type columns from that data.
The form renders one field per item in the bound array.
Mapped fields support a subset of configuration — some type-specific options may not be available when mapping.

Note: For Date fields in mapped mode, Disable Past Dates is the only extra date-formatting option that can be mapped from the data source.

Methods

Call these from any event with the Trigger Component Method action targeting the form, or directly from a script or expression targeting the form's ID.

Method	ID	Parameters	What It Does	Available When
Submit	`submitForm`	—	Validates, then submits. The action fails (and chained actions do not run) if the form is disabled, read-only, or invalid.	Always
Reset	`resetForm`	Reset to Default	Clears user entries and returns fields to their configured defaults. Also clears validation errors and returns the form to its "silent" pre-submit state.	Always
Validate	`validateForm`	—	Runs validation and shows errors without submitting. The action does not fail when the form is invalid — check `{{ form1.errors }}` afterwards.	Always
Reset Field	`resetField`	Field, Reset to Default	Resets one field to its default, or empties it when Reset to Default is off. Shown in the Method Name dropdown only once it is already set on the action — use Reset Fields otherwise.	Always
Reset Fields	`resetFields`	Fields, Reset to Default	Resets several fields at once in a single call. With Reset to Default off, the fields are emptied.	Always
Set Field Value	`setFieldValue`	Field, Value	Sets one field's value. Fires the field's On Change (and the form-level On Change), just as a user edit would. Shown in the Method Name dropdown only once it is already set on the action — use Set Fields Value otherwise.	Always
Set Fields Value	`setFieldsValue`	fields and values	Sets several fields' values in one call.	Always
Set Field Focus	`setFieldFocus`	Field	Moves keyboard focus to the specified field.	Always
Set Form Data	`setFormData`	form data	Replaces the whole form's data in one call. Use when pre-populating a Schema-source form.	Schema source only

Events

Form-Level Events

Event	Trigger	Payload
On Submit	Form submitted and all validation passed.	`formData` — the full set of field values as an object keyed by field key.
On Change	Any field's value changes. If that field has its own On Change, it runs first; then this form-level On Change runs once.	`formData`, `fieldId`
On Focus	A field gains focus. The field's details appear in `context.currentField`.	`formData`, `fieldId`
On Blur	A field loses focus.	`formData`, `fieldId`

Accessing Event Data

Inside an event's actions, the payload is available directly: {{ formData }} holds the field values keyed by field key (for example {{ formData.email }}), and {{ fieldId }} is the key of the field that changed, gained focus or lost focus. You can also read the form's state at any time, for example {{ form1.data }} and {{ form1.errors }}. The full state table is in Form Overview & Appearance → Exposed State.

Behavior & Gotchas

Warning: A validity rule on a hidden or disabled field never runs. Validity rules are skipped for hidden or disabled fields. A read-only field is different — its rules still run. If a validity condition "never triggers", check whether the field is hidden or disabled at submit time.

Note: Hidden fields are deleted from the form's data and submit payload. A field hidden by a visibility condition sends no key in the submit payload. A required field that is hidden also does not block submission — its required check is skipped. This makes the "required + visible only when relevant" pattern safe.

Warning: A re-shown field comes back with its default, not the prior entry. Hiding a field deletes its value. When it reappears it fills from its default, not what the user had entered before.

Note: A field a user has no permission for is removed, not just greyed out. By default, a permission-failed field is taken out of the form completely — two users on the same form can see different sets of fields. A required permission-removed field does not block submission for the user who lacks permission. Set "when no permission" to read-only to keep the field visible but uneditable.

Warning: submitForm fails without telling the user when the form is disabled or read-only. Calling Submit (submitForm) while the form is disabled, read-only, or invalid makes the action fail, and the actions chained after it in the sequence do not run. For a disabled or read-only form nothing appears on screen; for an invalid form the field errors show. Add an On Error branch if you need to react.

Step-by-Step Examples

Cross-Field Validation: Password Confirmation

Add a Password field with key password.
Add a second Password field with key confirmPassword.
On the confirmPassword field, open Validation → Validity conditions.
Add a rule: condition = {{ form1.data.confirmPassword }} equals {{ form1.data.password }}.
Set the error message: "Passwords do not match."

Pre-populate a Form with Record Data

Set the form's Source to Object.
Set Action to Update.
Bind Record ID to the record's ID, e.g. {{ myTable.selectedRow.id }}.
The form auto-populates from that record. The user edits and submits to update it.

Call validateForm Before Navigating Away

On a "Next" button's click event, add a Trigger Component Method action targeting the form.
Choose the Validate method (validateForm). This shows the errors but does not stop the action sequence.
Add a condition after it that checks {{ form1.errors.length }} equals 0.
Add a Go to Page action on the branch where the condition is true, so navigation only proceeds when the form passes validation.

To validate and submit in one step, use submitForm instead — it fails the action sequence when the form is invalid.

Reset a Specific Field on Another Field's Change

On the controlling field's On Change event, add a Trigger Component Method action targeting the form.
Choose the Reset Fields method and pick the dependent field. Leave Reset to Default off to empty it, or turn it on to restore its default.
The dependent field resets whenever the controlling field changes.