Appian SAIL Interfaces Interview Guide

SAIL (Self-Assembling Interface Layer) is Appian's declarative UI framework. In traditional HTML/CSS you define where every element sits, pixel by pixel. In SAIL you call component functions (a!textField, a!gridLayout and so on) and Appian renders them responsively across desktop, tablet, and mobile. A SAIL interface is an expression rule: it is evaluated server-side and the result, a serialized component tree, is sent to the browser. That keeps the UI logic next to your data layer, so it integrates tightly with Appian's rules and records.

Local variables, declared with a!localVariables, hold data that only exists inside the interface expression: whether a section is expanded, a search term, the selected tab, a value calculated once and reused in several places. You update one through a component's saveInto, either directly (saveInto: local!searchTerm) or with a!save() in a list of saves. Use them for anything that does not need to be stored anywhere; data that has to be kept should end up in a rule input or be written to the database.

Rule Inputs are parameters passed to an interface from an external caller (a process model, another interface, or a record action). You declare them at the top of the interface expression rule, in the Rule Input tab of Appian Designer, and reference them inside the interface as ri!parameterName. Rule Inputs are read-only inside the interface, so you cannot modify one 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.

All three are layout components with different structural jobs. a!formLayout is the top-level wrapper for a user task form: it provides the Submit and Cancel buttons and handles form submission. a!sectionLayout groups related fields under an optional title and can be collapsed or expanded; it does not handle submission. a!columnsLayout splits content into side-by-side columns. In practice, use a!formLayout as the root of a task form, nest a!sectionLayout for grouping, and use a!columnsLayout where you need two or three columns of fields.

You build an editable grid with a!gridLayout, putting editable components in each row. The pattern: (1) hold the grid data in a local variable or rule input as a list; (2) build the rows with a!forEach and save each field back to its row with fv!item or index; (3) add or remove rows by changing the list. Common pitfalls: forgetting that a variable with no initial value is null, which breaks comparisons and functions until you cast or default it; and not validating each row.

Each user interaction re-evaluates the interface. Expressions placed directly in components run again every time, while a local variable is only recalculated when its refresh settings say so. Common causes of extra work: (1) calling a!queryRecordType() inline in a component instead of storing it in a local variable, so it runs on every interaction; (2) a query in a local variable that references something which changes often, since by default a local variable refreshes whenever a variable it references changes; (3) setting refreshAlways: true in a!refreshVariable, which recalculates after every interaction. To prevent it, keep queries in local variables and use a!refreshVariable with refreshOnVarChange so they refresh only when the variable that matters changes.

SAIL validation uses the "validations" parameter on a!formLayout and many field components. You provide a list of validation messages as strings. When the submit button on a!formLayout is clicked, Appian evaluates every validation and blocks submission if any of them returns a non-empty string. Field-level validations appear below the field; form-level validations appear at the top of the form. "validationGroup" ties a set of validations to a specific button, which is useful on multi-step forms. Custom cross-field logic goes in the "validations" parameter of a!formLayout as if() expressions that reference Local Variables.

A user task form belongs to an existing process instance that is waiting at a User Input Task node. The user completes the form and that specific instance resumes. a!startProcess() starts a brand new process instance from inside SAIL, usually from a button onClick on a record action or a 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 a user action should kick off a background process without sending the user through a structured task flow.