Conditional Field Visibility
Forms that show every possible field for every possible situation are hard to use. A 40-field form for an order that's relevant only in specific configurations, depending on type, status, and payment method, overwhelms users who need to fill in 8 fields.
Conditional field visibility solves this by making forms adaptive: they show what's relevant for the current record state and hide what isn't.
Conditions Drive Visibility
Each field can be configured with a visibility condition. The condition is a rule: "show this field when [field] is [value]" or "hide this field when [field] is not [value]."
An "international shipping" details section appears only when the delivery country is not the home country. A "purchase order number" field appears only when the payment method is "invoice." A "cancellation reason" field appears only when the status is "cancelled." In each case, the field is irrelevant until the condition is true — and when it's irrelevant, it doesn't add noise to the form.
Multi-Condition Logic
Conditions can be combined. A field can be visible when status is "active" AND payment method is "invoice" AND credit limit is exceeded. Conditions support AND and OR logic, and they can reference any field on the same record or any field on a related record.
The platform evaluates conditions in real time as the form is filled. Change the payment method field, and the fields that depend on it appear or disappear immediately. No page refresh, no form reload — the form adapts as the user fills it in.
Different Fields for Different Record Types
A single object type can serve multiple record variants with different fields. An "order" type might include subscription orders, one-time orders, and custom orders — each with a distinct set of relevant fields.
Rather than creating separate object types for each variant, a type selector field drives the visibility of variant-specific fields. The form transforms as the type is selected, showing the right fields for the selected variant.
Required Fields Follow Visibility
A field that's hidden because its visibility condition is false is also not required, even if it's marked required in the field definition. Visibility and required status are evaluated together: if you can't see a field, you can't be expected to fill it in.
This prevents validation from blocking form submission with errors about fields the user has no way to fill in.
Simpler Forms, Faster Data Entry
The primary benefit is speed. Operators filling in forms with 10 visible, relevant fields work faster than operators navigating around 40 fields and ignoring the 30 that don't apply. Fewer fields to scan, fewer decisions about whether each field applies.
Adaptive forms reduce cognitive load. Users focus on the actual task, not on the interface.