9.1 SAIL Framework & Component Hierarchy

SAIL Interfaces and Component Composition

SAIL, the Self-Assembling Interface Layer, is Appian's declarative interface framework. An interface expression describes layouts, fields, and interactions. The platform renders that definition in supported browser and mobile experiences. The Associate Developer exam focuses on constructing a usable interface, selecting valid components, configuring inputs and saves, and testing the result.

The interface is an application design object, distinct from a record type or process model. A process can call it as a start or task form; a site can display it as a page; a record view can pass it record context. Reusing the interface does not automatically supply every caller's variables. Define rule inputs for the data the screen needs.

Choose the Screen Structure

Use a!formLayout() for forms needing a title, contents, and a standard button area. For a dashboard or record view, a list of components or an appropriate supported layout such as a!headerContentLayout() may suit the design. The old a!dashboardLayout() is deprecated and is not the standard choice for new interfaces.

A reusable child interface often returns a section or collection of components. It should not wrap itself in another top-level form when embedded inside a parent form. Select layouts according to the allowed nesting of their parameters, not a universal rule that every screen must contain the same hierarchy.

For columns, columns accepts column-layout objects, not a bare text field. A column's contents contains the fields. Likewise, a form's buttons expects the appropriate button layout. Reading the parameter's accepted type resolves many invalid component errors before runtime.

Construct a Small Form

This self-contained example separates stored interface state from the displayed component. It demonstrates a dropdown's labels and values without relying on pre-existing application objects.

a!localVariables(
  local!subject: "",
  local!priority,
  a!formLayout(
    label: "New Support Request",
    contents: {
      a!sectionLayout(
        label: "Request Details",
        contents: {
          a!textField(
            label: "Subject",
            value: local!subject,
            saveInto: local!subject,
            required: true
          ),
          a!dropdownField(
            label: "Priority",
            placeholderLabel: "Select a priority",
            choiceLabels: {"Normal", "High"},
            choiceValues: {1, 2},
            value: local!priority,
            saveInto: local!priority,
            required: true
          )
        }
      )
    }
  )
)

The dropdown displays labels but saves numeric values. There are two labels and two values. A saved value must match an available choice. Adding a third label without its corresponding value creates an invalid definition. In a real workflow, use typed rule inputs and the caller's mappings for information that must survive task submission.

Select Input Components

Use text or paragraph fields for text, integer fields for whole-number quantities, decimal fields for fractional values, date fields for dates, and date-time fields when time matters. A dropdown suits a compact choice set; radio buttons make a small exclusive set visible; checkboxes or a multiple dropdown support multiple selections.

Inspect the component's actual parameter list. Parameters are not universal: a property supported on one layout or field may not exist on another. Use the documented validations mechanism for date bounds rather than inventing minDate or maxDate parameters. Decimal display formatting also needs the supported component or formatting function rather than an assumed decimalPlaces argument.

Display Information Clearly

Use rich text for formatted labels and links, tags for compact statuses, images for visual content, and the appropriate chart or grid for structured data. A link constructor such as a!recordLink belongs inside a component that accepts links; it is not itself a general display field for every container.

Status text must remain understandable without color. Approved with a green tag is clearer than an unexplained green dot. Supply meaningful labels, alternative text, and the documented accessibilityText where needed. Platform components help with accessibility, but developers still control content, contrast, navigation, and labeling.

Responsive Behavior

Column layouts support semantic and relative widths. Their parent a!columnsLayout uses stackWhen to configure responsive stacking. Current documentation identifies the PHONE breakpoint as a width of 480 pixels or less. Do not substitute a blanket 768-pixel mobile rule or the obsolete stackOnMobile parameter.

Preview desktop, tablet, and phone configurations in Interface Designer. Check long labels, empty grids, large values, and buttons. A screen that looks balanced with a two-word company name may fail with a long legal name. On Appian Mobile, verify supported component behavior and any offline restrictions relevant to the use case.

Test Composition and State Together

Test every user interaction that changes the screen. Confirm that value reads the expected variable and saveInto updates it. Change dropdown choices, trigger validation, hide and show conditional sections, and test clear/reset behavior. Hiding a field does not automatically clear its prior value.

Use small reusable child interfaces for repeated address or review sections. Pass data through their rule inputs and bind editable inputs to valid parent variable references. Passing a computed copy is suitable for display but may not provide the writable target the child needs.

Worked Design Choice

A loan-review task needs applicant information, a risk summary, a decision dropdown, and comments. Use a form layout with clear sections and a submit button. Read-only applicant data and editable decision data have different roles. An executive dashboard showing totals and a record-backed queue can instead use a component collection or header-content layout.

Keep database authorization in the record and process security configuration. showWhen controls visibility, and read-only fields control interaction; neither alone authorizes a business transaction. On submission, the workflow should validate the current record and the permitted decision before persisting it.

Takeaway: Build valid component trees, separate display from saved state, and test the actual caller and device contexts.

Sources checked 2026-10-18: deprecated dashboard layout, columns layout, buttons, and interface reuse.