AEP cheat sheet

Appian is a low-code automation platform whose runtime is a Java-based application server; the Appian Engines (process, expression, etc.) run as separate JVM processes managed by the Appian service manager.

The Appian environment consists of web application servers, search servers (Apache Solr-based), a relational database (supported: Oracle, SQL Server, MySQL, PostgreSQL), and a shared file system for documents and temporary files.

Appian Cloud is a managed deployment; Appian on-premises requires the customer to provision the database, file server, and Java runtime (JDK 11 or 17 depending on version).

The Appian Health Check is a built-in administrative tool that runs diagnostics on system configuration, performance, and security and produces a scored report.

Appian uses a three-tier logical architecture: presentation (web/mobile clients), application (Appian engines and web server), and data (RDBMS and file system).

The Appian product version determines available features; the compatibility matrix on Appian Community documents supported database, JDK, and browser versions.

A site is a collection of pages and actions published to a URL; the Tempo interface (now called Appian Sites) provides a unified user entry point.

Appian's expression language is used across interfaces, process variables, and record fields; expressions are evaluated by the expression engine and are stateless.

A record type defines a business entity; it is backed by a data source such as a database table, a web service, a process variable, or a Salesforce object.

Record fields map to columns or attributes; each field has a type (Text, Integer, Date, Boolean, etc.) and can be marked as a key, a label, or a searchable field.

Relationships between record types are defined by one-to-many or many-to-one mappings using a foreign key field; these enable related record queries and record links.

A record type can be created from a database table, a view, or a web service; the data source determines whether the record is read-only or writable.

Record-level security is configured via record type roles (Viewer, Editor, Administrator) and can be filtered by field-level security expressions.

A record list view uses a query (e.g., a!queryRecordType) with filters, sorting, and paging; the default query returns up to 100 rows unless paging is configured.

Data store entities (older feature) map directly to database tables and are used for write operations; record types are the modern abstraction for read and write.

Record type actions (Create, Update, Delete) are process models that are triggered from record views and use the record type's data source to persist changes.

An interface is defined using SAIL (Self-Assembling Interface Layer) with a! components; the root component must be a layout (e.g., a!formLayout, a!headerContentLayout).

Interface variables are declared with a!localVariables or as rule inputs; local variables are evaluated in order and can reference earlier variables in the same block.

A!buttonWidget with saveInto and value triggers a process model via a!startProcess or a!submitUpload; the submit action is configured in the form layout's buttons parameter.

Conditional display is controlled by the showWhen parameter on any component; visibility can also be governed by a!isNotNullOrEmpty or other boolean expressions.

A grid uses a!gridField with columns defined by a!gridColumn; each column's value can be an expression, and sorting and paging are configured via the grid's parameters.

The a!recordData() function provides a data subset for a record type, which can be used in grids, charts, and dropdowns without writing a query each time.

Validation errors are shown using a!validationMessage on a component or by returning a validation error from a process model; the interface can display errors using a!validationMessage or a!paragraphField with validations.

The a!formLayout component automatically provides a title bar, buttons, and a validation summary; the buttons parameter accepts a!buttonLayout with submit and cancel buttons.

A process model is a BPMN-like diagram of nodes: start/end events, user input tasks, service tasks (e.g., script task, integration), gateways (XOR, AND), and timers.

Process variables are defined at the process model level and can be typed as Text, Integer, Boolean, or a custom data type; they are passed to and from nodes.

A user input task is assigned to a user or group via the Assignments tab; the task form is an interface, and the task can have a deadline and escalation.

An XOR gateway routes the token down exactly one outgoing path based on the first true condition; an AND gateway activates all outgoing paths.

A script task executes an expression and can set process variables; it does not pause the process and is used for data transformation.

A timer event can be configured as a boundary event (interrupting or non-interrupting) or as an intermediate event; durations use ISO 8601 format (e.g., P1D for one day).

A subprocess encapsulates a reusable set of nodes; it can be embedded (inline) or a separate process model called via a start process or a!startProcess.

Process instance priority and escalation can be set; the process execution engine stores state in the Appian database, enabling recovery after restart.

An integration is a reusable configuration that connects to an external system via HTTP, SOAP, or a custom protocol; it is created in the Integrations designer.

A connected system defines the base URL and authentication (e.g., OAuth 2.0, basic auth, API key) for one or more integrations.

Integration objects have inputs and outputs; the output is mapped to a custom data type or an Appian data type for use in expressions and process models.

The a!integration() function or the Call Integration smart service invokes an integration; errors are returned as an IntegrationError and can be handled with a!errorInfo.

A web service (SOAP) can be imported via a WSDL; Appian generates the integration object and data types from the WSDL definition.

REST integrations support GET, POST, PUT, DELETE, and PATCH; the request body can be JSON or XML, and the response is parsed into an Appian data type.

Authentication for integrations can use OAuth 2.0 client credentials, authorization code, or basic auth; credentials are stored securely in the connected system.

Integration timeouts and retry policies are configured on the integration object; the default timeout is 30 seconds, and retries can be set for transient failures.

Appian security is role-based: users are assigned to groups, and groups are granted roles on objects (e.g., process models, record types, folders).

Object security is configured via the Security tab; roles include Viewer, Editor, Administrator, and custom roles; permissions are additive across groups.

Authentication can be native (Appian database), LDAP/Active Directory, SAML 2.0, or OpenID Connect; authentication is configured in the Administration Console.

Single sign-on (SSO) with SAML requires an identity provider (IdP) and a service provider (Appian); user attributes can be mapped to Appian user fields.

Authorization is enforced at the object level and at the data level via record type roles and field-level security expressions.

The Administrator role on the Administration Console grants access to system settings, user management, and security configuration.

Process model security can be set to allow only certain groups to start or view the process; the process instance's security is inherited from the process model unless overridden.

A user's effective permissions are the union of permissions from all groups they belong to; explicit deny is not supported, so permissions are only granted.

An application is packaged into an application package (ZIP) for deployment; the package includes objects, data types, and configuration.

Deployment can be performed via the Appian Administration Console (Deployment tab) or via the Appian Deployment REST API; environments must have compatible Appian versions.

A deployment checklist includes verifying object dependencies, data source mappings, and security role mappings between environments.

Appian provides a testing framework via the Expression Rule test cases and process model test cases; automated testing can be integrated with CI/CD pipelines.

The Appian Health Check should be run after deployment to verify system integrity; it checks for misconfigurations and performance issues.

Log files (e.g., appian.log, process-execution.log) are located in the <APPIAN_HOME>/logs directory; log levels are configured in the logging configuration.

Backup and recovery involve database backups and file system backups; Appian Cloud provides automated backups, while on-premises requires a customer-defined backup strategy.

The Appian Administration Console provides monitoring of system health, active users, and process instances; the Process Monitoring tab shows running and completed processes.