Appian ACD201 cheat sheet

A record type defines the schema for business data; each record type has fields, relationships, and optionally a data source (database table, web service, or process).

Field types include Text, Integer, Decimal, Date, Date and Time, Boolean, User, Group, Document, and Record; each maps to a specific underlying storage type.

Relationships between record types are defined as one-to-many, many-to-one, or many-to-many; many-to-many requires a join record type.

A record type can be backed by a database table (synced), a web service (external), or a process (process-backed); synced record types support filtering and aggregation in queries.

The primary key field uniquely identifies each record; for database-backed record types it must map to a column with unique values.

Record type fields can have validation rules (e.g., required, unique, regex) that are enforced on save via the record type's data management settings.

Data fabric queries use aQL (Appian Query Language) to retrieve records; aQL supports filters, logical operators, sorting, and aggregation functions like COUNT and SUM.

A record type can have multiple data sources (e.g., a synced table plus a web service) combined in a single record type using a data source precedence order.

Cascading deletes are configured on relationships; deleting a parent record can automatically delete related child records if the relationship is set to cascade.

A process model is a diagram of automated steps; each step is a node type such as Start, User Input Task, Service Task, Script Task, Gateway, Timer, or End.

User Input Tasks assign work to users or groups via assignment settings; the task form is defined by an interface or a form.

Gateways (XOR, AND, OR) control branching; XOR takes one path, AND takes all paths, OR takes one or more paths based on conditions.

Process variables store data during execution; they can be process variables, node inputs/outputs, or parameters passed to subprocesses.

A subprocess is a separate process model called from a parent process; it can be synchronous (parent waits) or asynchronous (parent continues).

Timers can be set on steps to trigger escalations, reminders, or timeouts; timer durations are defined in business calendars or absolute times.

Process models can be started by a record action, a process start event, a scheduled process, or a web service call.

Exception handling uses error events or boundary events; an error event can be caught by a boundary error event on a subprocess or a start error event.

The process model can include automated service tasks that call integrations, such as a web service or an Appian plug-in function.

An interface is defined using SAIL (Self-Assembling Interface Layer); components are declared with functions like a!textField, a!buttonLayout, and a!gridField.

SAIL components are evaluated top-down; variables declared with a!localVariables are scoped to the interface and can be used in expressions.

Layout components (e.g., a!sectionLayout, a!cardLayout) organize the page; input components (e.g., a!textField, a!dropdownField) capture user data.

A form is an interface with a submit button; the submit button's saveInto parameter writes values to a rule input or process variable.

Validation is performed with a!validationMessage or by setting the validations parameter on input components; invalid forms cannot be submitted.

Dynamic behavior is achieved with conditional visibility (showWhen), disable (disabled), and choice filtering (filterable, choiceLabels).

A record list or grid can be displayed using a!gridField with data from a!queryRecordType; columns are defined with a!gridColumn.

The interface's rule inputs are passed from the process or record action; they are read-only unless explicitly saved into.

Styling is controlled by the interface's theme and component style parameters; custom branding is applied via the application's theme.

An integration is a reusable connection to an external system; it defines the endpoint, authentication, and request/response mapping.

Integration objects support REST, SOAP, and Appian Web API; they can be called from a process model or an interface via a!integration.

Authentication methods for integrations include Basic Auth, OAuth 2.0, API key, and custom headers; credentials are stored in a connected system.

A connected system stores base URL and authentication details; integrations reference a connected system to inherit those settings.

Request and response mappings use expressions to transform data between Appian and the external system; JSON and XML are supported.

Error handling in integrations uses the onError parameter or a!integration's error handling; errors can be logged or escalated.

Appian Web APIs expose process models, record types, and reports as REST endpoints; they are secured by API keys or OAuth.

A web service can be imported as a WSDL to create a SOAP integration; the WSDL defines operations and data types.

Integration timeouts and retries are configured in the integration object; default timeout is 30 seconds unless overridden.

Security is applied at multiple levels: application, record type, process model, interface, and folder; each object has its own security settings.

Users and groups are managed in the Administration Console; groups can be nested and can contain other groups.

Object security uses role-based access: Viewer, Editor, Administrator, and custom roles; permissions are granted to users or groups.

Record type security includes record-level security (row-level) via a security expression that filters records based on user attributes.

Process model security controls who can start the process and who can view the process instance; it can be set to public, groups, or users.

Authentication can be via Appian internal, LDAP, SAML, or OAuth; single sign-on (SSO) is configured in the Administration Console.

A user's group membership determines their access; a user can belong to multiple groups, and permissions are additive.

Folder security controls access to objects stored in a folder; it can be inherited by child objects.

API keys are used to authenticate to Appian Web APIs; they are generated for a user and inherit that user's permissions.

Deployment moves objects between environments (e.g., Development, Test, Production) using a deployment package or an application.

An application is a container for related objects; it can be exported as an application package (ZIP) for deployment.

Deployment packages can include dependencies; the deployment process checks for missing dependencies and may fail if objects are missing.

The Administration Console provides monitoring of process instances, health check, and system logs; it also manages users, groups, and connected systems.

Performance tuning includes optimizing database queries (indexes, aQL filters), reducing process model complexity, and using caching.

Process instance cleanup and archiving are configured to manage database growth; archived instances are moved to a separate table.

Health check reports on system status, including memory, CPU, and database connectivity; it can be scheduled.

Logging levels (ERROR, WARN, INFO, DEBUG) are configured per logger; logs are accessible in the Administration Console or log files.

Backup and recovery involve database backups and file system backups; Appian provides scripts for backup and restore.