Appian ACD101 cheat sheet

A record type is a design object that models business data; it defines fields, relationships, views, actions and security, and is backed by a data source such as a database table, web service, Salesforce object, process, or Appian data store entity.

Every record type requires a primary key field - the field whose value uniquely identifies a record; relationships and record-level security depend on it.

Relationship types between record types are one-to-one, one-to-many, many-to-one and many-to-many; each is configured with a source field and a destination field.

A CDT is an XSD-defined custom data type used for process variables, node inputs and rule inputs; database-backed record types expose a matching data type in the data model.

Record types are referenced in expressions as recordType!Employee, and their fields as recordType!Employee.firstName.

XOR gateways continue down exactly one outgoing path (the default flow when no condition is true); OR gateways take one or more paths; AND gateways take all outgoing paths.

A user input task presents an interface as a form and pauses the process until an assigned user or group submits it.

Process variables are declared on the Process Variables tab of the process model and referenced in expressions with the pv! prefix.

Node inputs feed values into an activity; node outputs store an activity's result into a process variable for later nodes.

A script task evaluates an expression automatically with no user interaction and writes the result to a node output.

Escalations on a user input task fire after a configured duration and can reassign the task to another user or group, or notify recipients.

Boundary timer events can be interrupting (they cancel the attached activity) or non-interrupting (the activity keeps running).

SAIL (Self-Assembling Interface Layer) interfaces are written as Appian expressions; each component is a function such as a!textField or a!gridField.

Forms and task forms are wrapped in a!formLayout, which takes contents plus a buttons list of a!buttonWidget components, normally grouped in a!buttonLayout.

Every input component pairs value (what is displayed) with saveInto (where the user's entry is written, for example ri!name or local!name).

a!save(target, value) used inside saveInto writes to multiple targets or transforms the value before saving.

a!localVariables(local!x: ..., ...) declares interface-scoped variables and is the supported replacement for the deprecated load() function.

a!gridField renders tabular data from a data source such as a!recordData(); each column is an a!gridColumn with its own value expression.

showWhen on a layout or component renders it only when the expression evaluates to true; style parameters change appearance but not visibility.

Inside an interface, inputs are referenced with ri! (rule and interface inputs) and local! (local variables), while fv!item is available inside a!forEach.

Rule inputs are declared on the expression rule and referenced inside it as ri!inputName; callers pass values by name without the ri! prefix.

Constants are typed design objects referenced with cons!, for example cons!MAX_AMOUNT, and are not editable at runtime.

String concatenation uses the & operator; numeric arithmetic uses + - * /; logical operators are and, or and not; equality is = and inequality is <>.

if(condition, valueIfTrue, valueIfFalse) selects between two values based on a boolean condition.

isnull() returns true only for null; an empty string or empty list is not null, so use isNullOrEmpty() when checking text or lists.

a!forEach(items, expression) evaluates the expression once per item and exposes fv!item, fv!index, fv!isFirst and fv!isLast.

append() merges lists into one list, union() merges and removes duplicates, and index(list, n, default) returns the nth item or the default.

Cast values with totext(), tointeger(), todecimal(), todate(), touser() and togroup(); casting an invalid value raises an expression error.

Every Appian object has role-based security with the standard roles Viewer, Editor and Administrator, granted to individual users or to groups.

Objects inherit security from their parent folder or application unless inherit security is unchecked and explicit roles are configured.

Group membership grants the permissions assigned to the group; groups may contain other groups, and nested membership is evaluated transitively.

Process model security determines who may start a process (Initiator role) and who may view or administer the process model.

Compare and Deploy compares objects between environments and deploys selected changes; alternatively an application can be exported as a ZIP and imported.

The Admin Console, reached at /admin, manages users, groups, authentication, data sources, plugins and system health settings.

Data sources are configured in the Admin Console; data store objects reference a data source to read from and write to an external database.

Service accounts are non-interactive user accounts used by integrations or background processing rather than by people.