SAIL Interfaces in Appian: What Interviewers Really Ask

SAIL (Self-Assembling Interface Layer) is Appian's declarative UI framework. Unlike traditional HTML/CSS where you define how elements are positioned pixel-by-pixel, SAIL uses component functions (like a!textField, a!gridLayout) that Appian renders responsively across desktop, tablet, and mobile automatically. SAIL interfaces are defined as expression rules — they are evaluated server-side, and the result (a serialized component tree) is sent to the browser. This means UI logic is co-located with your data layer, enabling tight integration with Appian's rules and records system.

Local Variables (declared with a!localVariables) store temporary UI state on the client — data that affects the interface but does not need to be persisted to the server or passed back to a process. Examples: whether a section is expanded/collapsed, a search term in a client-side filter, the currently selected tab. Local Variables are updated using a!save() within component event handlers (onUserChange, onClick). Use Local Variables to avoid unnecessary server round-trips — only send data to the server when the user explicitly submits the form.

Rule Inputs are parameters passed to an interface from an external caller (a process model, another interface, or a record action). They are declared at the top of the interface expression rule in the Rule Input tab of Appian Designer. Inside the interface, they are referenced as ri!parameterName. Rule Inputs are read-only within the interface — you cannot modify a Rule Input directly. If you need to display and edit the value, copy it into a Local Variable first. Rule Inputs are set when a task form opens or when an interface is invoked via a!startProcess.

These are layout components with different structural roles: a!formLayout is the top-level wrapper for a user task form — it provides Submit/Cancel buttons and handles form submission. a!sectionLayout groups related fields with an optional title and can be collapsed/expanded; it does not handle submission. a!columnsLayout divides content into side-by-side columns for multi-column layouts. Best practice: use a!formLayout as the root of task forms, nest a!sectionLayout for grouping, and a!columnsLayout for two- or three-column field arrangements.

An editable grid is built using a!gridLayout (with editable fields inside each column) or a!gridField with editable components. For editable grids: (1) Store the grid data in a Local Variable as a list of CDTs; (2) Use index() and a!save() to update individual row values on user change; (3) Add/Remove rows by manipulating the list in a Local Variable. Common pitfalls: forgetting to initialize the Local Variable with at least one empty CDT row (causing null reference errors); using process variables for grid data (causes unnecessary server calls on every edit); not handling validation per-row.

SAIL interfaces re-evaluate whenever a!save() is called (changing a Local Variable). Every re-evaluation re-runs the entire expression rule. Common causes of excess re-evaluations: (1) calling a!queryRecordType() or a!query() outside of a!localVariables "initialValue" (re-queries on every change); (2) complex computed expressions that depend on frequently-changing local variables; (3) using refreshAlways on rule inputs. Prevention strategies: move expensive queries into a!localVariables with refresh set to "REFRESH_AFTER_EACH_SAVE"; use a!refreshVariable sparingly; structure the interface so only relevant sections re-evaluate.

SAIL validation uses the "validations" parameter present on a!formLayout and many field components. You provide a list of validation messages (strings) — when a!formLayout's submit button is clicked, Appian evaluates all validations and prevents submission if any return a non-empty string. Field-level validations appear below the specific field; form-level validations appear at the top of the form. You can also use "validationGroup" to group validations that trigger on a specific button (useful for multi-step forms). Custom cross-field validation logic goes in a!formLayout's "validations" using if() expressions referencing Local Variables.

A user task form is launched by an existing process instance waiting at a User Input Task node — the user completes the form, which resumes that specific process instance. a!startProcess(), by contrast, starts a brand new process instance from within SAIL (typically from a button onClick event on a record action or standalone form). Use user task forms for approval workflows and guided multi-step processes. Use a!startProcess from a record action or event button when you need to kick off a background process in response to a user action without requiring the user to go through a structured task flow.