Appian ACD301 cheat sheet

A record type is backed by one data source; record type fields map to columns, relationships, or custom computed values, and each field has a distinct field type (primitive vs. reference).

One-to-many relationships are stored on the child record type as a reference field to the parent; the parent side is a reverse reference and stores no column.

A many-to-many relationship requires a junction record type holding two reference fields, one to each side.

Record type field types include Text, Integer, Decimal, Boolean, Date, Date and Time, Time, User, Group, Document, and Record (reference).

Data store entities are created for each record type; the data store holds the connection (database, web service, or Appian) and must be synced before the record type can query data.

A record type can be sourced from a database table, a web service (via integration), a process-backed entity, or an Appian-managed (auto-generated) table.

Local variables in an interface should match record field types; mismatches between a!localVariables and a!save targets cause runtime type errors.

Query record types (views) are read-only and cannot be written to unless they map to a writable base record type; use a!queryRecordType with filters and paging.

Record-level security is enforced on the record type; field-level security can be applied per field to hide sensitive columns from certain groups.

Process model node types: Start, End, Activity (user/task), Automated (script/integration), Gateway (XOR/OR/AND), Timer, Subprocess, and Event.

An XOR gateway routes to exactly one outgoing path; an OR gateway routes to one or more paths based on conditions; an AND gateway splits to all paths and waits for all to complete on join.

Process variables are scoped to the process instance; use a!save or the Data tab to write values; ACP (Appian process) variables persist across nodes.

A user input task node requires an assigned user or group; the task form is a SAIL interface and can write to process variables via a!save.

A subprocess node runs another process model synchronously or asynchronously; async subprocess does not block the parent and can be used for long-running work.

A timer event can be a one-time delay or a recurring schedule; timers require the process to be in a wait state (e.g., a timer event or a user task).

Error handling: attach an error boundary event to a node to catch exceptions; unhandled errors escalate to the process administrator and can terminate the instance.

Process model security is set via process model properties (who can start, who can view); task assignment and process initiation are separate permissions.

Escalations can be configured on user task nodes to reassign or notify after a time threshold; escalation actions include reassign and send email.

SAIL interface components: a!formLayout, a!sectionLayout, a!columnsLayout, a!cardLayout, a!textField, a!dropdownField, a!gridField, a!buttonWidget.

a!localVariables declares interface-local variables with a!localVariables(local!x: value, ...); reference them as local!x and update with a!save.

a!save(target, value) writes to a variable or rule input; a!save with a list of saves applies multiple writes; saveInto on a component triggers on user interaction.

Validation: use validations on components (e.g., required: true) and a!validationMessage; conditional display uses showWhen.

Dynamic behavior: a!refreshVariable with refreshOnReferencedVar or refreshInterval controls recalculation; without it, variables do not auto-refresh.

a!gridField requires columns with a!gridColumn and data as a list of dictionaries or CDT; use a!gridRowLayout for custom row rendering.

Records and interfaces: use a!recordData or a!queryRecordType to fetch record data; a!recordActionField or a!recordActionItem launches record actions.

a!buttonWidget with saveInto and value triggers navigation via a!startProcess or a!link; use a!submitLink for form submission.

Interface performance: minimize repeated queries, use a!refreshVariable with refreshOnReferencedVar false for static data, and avoid large grids without paging.

An application is a container for objects (record types, process models, interfaces, groups); objects are organized into groups and pages in the application designer.

Security is group-based: users belong to groups; groups are granted permissions on objects (viewer, editor, administrator); object security inherits from the application by default.

Permission types include Viewer, Editor, Administrator, and Initiator (for process models); record type permissions include Viewer, Editor, and Administrator.

Deployment: an application can be exported as an application package (ZIP) containing objects and dependencies; import into another environment via the Admin Console or Appian Designer.

Deployment objects include record types, process models, interfaces, groups, and constants; data is not deployed, only object definitions.

Environment-specific values should be stored in constants or environment variables; use a constant with an environment-specific value rather than hard-coding.

Object versions: each save creates a new version; you can compare versions and revert; deployments carry the latest version unless a specific version is selected.

The Admin Console manages users, groups, and system settings; application security is configured in Appian Designer under the application's security settings.

Publishing an application makes it available to users; unpublished changes are in design mode and not visible to end users until published.