Interfaces and User Experience
Components, layouts, and expressions
An interface is a tree of components (layouts, grids, input fields, buttons) evaluated by SAIL expressions. The same interface can render on web and mobile, so layout choices matter. Local variables hold UI state; rule inputs pass data in; saveInto targets bind user input back to variables. Validation is expressed through component-level validations and through validation groups.
Actions and forms
A start form or task form is an interface bound to a process. A record action is an interface that writes to a record. Related actions and process actions launch from a record. Understanding which interface type a scenario needs is a common discriminator.
Traps to watch for
- Assuming a local variable persists across a process. It lives only for the interface's lifetime.
- Confusing saveInto (bind input to a variable) with a submit action (which triggers a process or write).
- Forgetting that a!refreshVariable controls when a variable recomputes; without it, values can look stale.
- Believing validation blocks navigation automatically. Validation groups must be wired to the button or form behavior.
- Overlooking accessibility: labels, instructions, and help text are expected on inputs.
Rule of thumb
Ask three questions for any UI question: Where does the data come from? (rule input, local variable, query), Where does user input go? (saveInto target), and What happens on submit? (process start, record write, or nothing). Most interface questions resolve on one of these three axes.
Worked example
A grid shows stale values after an edit. The grid's data comes from a local variable computed with a query; because it is not configured to refresh when the underlying variable changes, it keeps the old result. Setting refresh behavior on the variable restores correct display.