Forms and validation
Forms support users when creating or editing records. A clear form shows what belongs to the current task, what is optional, and how users can correct an invalid entry. The validation reference defines the technical validation model and available configuration.
Structure forms around the task
Place information in the order in which users need it to complete the task, not in the order in which it happens to be stored. Group fields that belong to one decision or work step, and give each group a clear purpose. A long form is easier to use when users can recognise what belongs together and where to continue after each group.
Give the create and edit flows their own review. A field that is needed only when a record is created, or that must not change after creation, should not make the other flow harder to understand. Internal identifiers and calculated values belong in a form only when they help users complete the task. Present calculated values clearly as information rather than editable input.
Keep recurring input consistent
Recurring fields are easier to complete when their labels, units, formats, and
input help remain familiar. A placeholder can clarify an expected value, but it
does not replace a visible label. Within one workflow, one wording pattern,
such as From – To or Start – End, avoids unnecessary variation.
When users need to read or copy a value without changing it, a read-only presentation is often more suitable than a disabled control, where the selected component supports it.
Use mandatory fields selectively
Make a field mandatory only when the record cannot be created or changed correctly without its value. A mandatory marker is not a substitute for explaining why a value is needed; field help or validation feedback should provide that context where it is not self-evident.
ADITO treats an empty field with the mandatory property as invalid. In the
documented client behavior, the Save action is disabled and the message
Required value is missing is shown. Review this behavior in the selected
viewtemplate and configuration, especially when mandatory fields are initially
hidden, filled by a process, or depend on another input.
Make validation feedback actionable
Use field-level validation for a rule concerning one field. Use entity-level
validation for rules that depend on several fields or on the record as a whole.
Field-level onValidation runs when the corresponding field loses focus;
entity-level onValidation runs when a user enters any field of the entity.
When a validation process returns text, the client treats the entry as invalid and shows that text to the user. Write the message in task language: identify the affected value or relationship, state the problem, and, where useful, explain the correction. For example, explain that an end date must be after the start date instead of exposing a technical rule name.
Do not use a blocking validation message for an advisory condition that users may reasonably accept.
Review completion and recovery
The selected viewtemplate determines the available save, cancel, and unsaved-change behavior. Test the configured form with representative data and record the observed behavior for the following situations:
- A user saves a valid new or changed record.
- A user tries to save with mandatory or custom validation failures.
- A user corrects one failure while another remains.
- A user cancels, navigates away, or opens another task after making changes.
Test devices and accessibility
Review the actual form on every supported device variant. Check that fields, labels, help, validation feedback, and completion actions remain visible and usable at the intended screen size and orientation.
For keyboard and assistive-technology use, verify a logical focus order, visible focus, clear field labels, and feedback that is available after a validation result. Custom controls and embedded content require a separate review because standard viewtemplate behavior does not automatically apply to them.
Form review checklist
| Review area | Questions to answer |
|---|---|
| Structure | Does the order and grouping follow the user's task in both create and edit flows? |
| Mandatory input | Is every mandatory field necessary, identifiable, and possible to complete in the current flow? |
| Validation | Does each rule run at the appropriate field or entity level and provide an understandable correction? |
| Messages | Are errors, warnings, and field help distinguishable without technical details or ambiguous wording? |
| Completion | Do save, cancel, navigation, and unsaved-change behavior match the reviewed configuration? |
| Devices and accessibility | Can users complete and correct the form on every supported device and with the required accessibility settings? |