Appian ACD301 key terms

A design object that defines a reusable data structure backed by a data store entity, grouping fields, relationships, and behaviors so the same business entity can be reused across interfaces, processes, and reports.

A mapping between an Appian record type and a table (or view) in a relational database, including column-to-field mappings and the database where the table lives.

A configured connection to a relational database, holding credentials and connection settings, used by data store entities to read and write persistent data.

A single named attribute on a record type, with a data type, that maps to a database column or is derived, and can be referenced in expressions, queries, and interfaces.

A defined association between two record types (one-to-many or many-to-one) that lets designers traverse related data in expressions and queries without writing manual joins.

A smart service or expression function that retrieves record data using filters, logical expressions, sorting, and paging, returning a datasubset rather than the entire table.

A user-defined composite type made of named fields, used to pass structured values between processes, rules, and interfaces without a database table.

The paged, filtered result set returned by record queries, containing the matching rows plus metadata such as total count and start index.

The technique of retrieving query results in batches using a start index and batch size, keeping large data sets performant in grids and process reads.

Role-based permissions on a record type that control which groups can view, create, update, or delete records, and which fields are visible to each audience.

A diagrammed workflow definition composed of connected nodes (activities, gateways, events) that specifies the sequence of automated and human tasks in a business process.

A named value scoped to a process instance that carries data between nodes and can be typed as a primitive, record, custom type, or list.

The category of a process node that determines its behavior, such as user input task, service task, script task, gateway, or timer event.

A process node that pauses execution and presents a form to a human assignee, resuming when the task is submitted or completed.

An automated process node that invokes a smart service, such as sending email, writing to a data store, or calling an integration, without human interaction.

A process node that branches or merges the flow based on conditions or events, including exclusive, inclusive, and parallel variants.

A branching node that follows exactly one outgoing path whose condition evaluates true, merging flows when multiple incoming paths arrive.

The configuration on a user input task that determines who receives it, such as a user, group, expression result, or dynamic assignee list.

A prebuilt, configurable process action that performs a specific operation, such as creating a record, sending a notification, or starting a subprocess.

A process node that starts another process model as a child instance, either synchronously (waiting for completion) or asynchronously.

A process event that triggers after a specified delay or at a scheduled time, enabling reminders, escalations, and time-based transitions.

A configured rule on a user input task that reassigns or notifies when the task is not completed within a defined time window.

A single running execution of a process model, with its own variable values, task history, and current position in the flow.

A design object that defines a screen or reusable UI component using SAIL, rendered as a form, dashboard, or wizard for end users.

Self-Assembling Interface Layer, Appian's declarative markup language in which interfaces are written as nested component functions that render dynamically based on data.

A reusable SAIL building block such as a text field, grid, button, or card layout that produces part of an interface's rendered output.

A SAIL component that arranges other components visually, such as columns, side-by-side panels, cards, or section headers, without capturing data.

An interface used to collect user input, typically bound to process variables or record fields and displayed inside a user input task.

Rules attached to inputs or forms that check submitted values and block submission with user-facing messages when requirements are not met.

A reusable expression saved as a design object that returns a value, allowing shared logic such as calculations, visibility conditions, or formatting to be referenced widely.

A written formula in Appian's expression language that evaluates to a value, used in rules, process configurations, and interface bindings.

A container design object that groups related record types, interfaces, process models, and rules, and is the unit that is packaged and deployed between environments.

A named collection of users used to grant permissions and assign work; groups can be nested and can include other groups as members.

A named set of permissions on an object that is granted to users or groups, controlling actions such as view, edit, or administer.

The per-object permission settings that determine which users and groups can view or modify a design object or its data.

The process of moving an application package from one environment to another, comparing objects and resolving differences before publishing to the target.

A distinct Appian instance, such as development, test, or production, that hosts applications and participates in the deployment lifecycle.

A bundled set of selected design objects exported from a source environment for inspection and import into a target environment during deployment.