Get Started with Applications

A Composition of Simple Pieces

In the Appian Application Platform, an application is a collection of objects that represents a business solution. An application functionally groups design objects, which form the UIs, logic, processes, and data users interact with while doing work in Appian. For instance, each of the following business needs would be built in a different application:

  • customer relationship management
  • sales opportunities
  • employee onboarding
  • performance review management

Designers also use applications to group common objects into libraries that are used by many applications. These common object applications prevent the need to create redundant supporting objects. Libraries may include:

  • email template rules
  • formatting and display rules
  • common constants for lists of countries or currency icons

Appian enables designers to create applications that show the right information to the right people at the right time and allow them to take the right action on it.

Design Objects

Each design object provides a specific piece of functionality, and each application comprises many objects grouped by common purpose. However, applications do not contain these objects, but simply have a list of objects that are associated with them. This means that a single object can be associated with one or more applications. Associating new objects with an application happens automatically when working within that application.

In addition to being associated with an application, objects reference each other, creating relationships between them. Related objects must be exported together when they are first deployed.

All design objects have a name, description, and modified by name and timestamp. With the exception of data types and group types, all design objects have a role map that determines their security. All design objects can be exported and imported to deploy them to other environments, such as from development to testing and production.

Application Application

Applications are also design objects, though their primary attribute is the list of objects associated with them. They also contain actions.

Actions are not design objects, but a configuration on an application. An action exposes one of the application's process models in Tempo in the Actions tab, and is only imported and exported along with that application.

Constant Constant

A constant holds a single user-defined value or list of values, such as 14, Customers (a record type), or a list of values.

A constant allows you to define a value once and then use it in many places in an application. If the value needs to be updated in the future, it only needs to be updated in one location. Constants are also used to reference other design objects in expressions. Common uses for constants include:

  • the number of days allowed for approval of a task
  • the standard label for all Submit buttons in the application, or
  • a reference to the Customer record to use in the 'queryrecord()' function

Data Store Data Store

A data store is a connection to an external relational database that is used to store application data. Each data store contains one or more data entities. When saving data from Appian to an external database, the data store defines the connection to the database, while data types (below) define the structure of the data entity being stored.

Data Type Data Type

A custom data type is a designer-defined data structure. Data used by Appian must conform to a data type. Designers define custom data types such as Customer or Purchase Request.

Designers may also use predefined system data types, such as Boolean, Text, or DataSubset, but these are not design objects that are added to an application.

Decision Decision

A Decision is a grouping of business rules that answers a specific question based on inputs.

Unlike expression rules, which primarily calculate or manipulate data, Decisions are best used to encapsulate complex, business-specific logic.

Decisions can be called from any expression, so they can be reused across multiple objects throughout the system.

Document Document

A document is a file stored in Appian. Appian provides a management system for documents.

While process reports are stored as documents, they have a unique icon and are sorted and filtered as reports.

Expression Rule Expression Rule

An expression rule is a stored expression that works like an Appian function, except that users can create their own rule inputs (to use as parameters) and definition.

Like all expressions, an expression rule is a statement that evaluates to return a value, much like a spreadsheet function. Common uses for expression rules include:

  • Returning a user's name if they are in the Managers group, and otherwise returning their title
  • Returning true if today is not a weekend day
  • Returning the first word in a string

Feed Feed

A feed is a channel for delivering content to the News Feed in Tempo. Every post or event in the News Feed that isn't directly created by a user has a feed associated with it. The names of all visible feeds show up in the feed catalog in Tempo, where users can subscribe or unsubscribe from them. Generally, designers use a separate feed for each topic for which their application creates events or comments.

Folder Folder

A folder contains objects; any object in a folder can only be in one folder. There are three types of folders:

  • Rule folders that contain expression rules, query rules, constants, and interfaces
  • Process model folders that contain process models
  • Document folders that contain documents

Other kinds of design objects are not stored in folders.

Group Group

A group allows designers to organize users, usually for the purpose of determining what permissions they have to design or use application objects and data. In addition, tasks and News entries can be targeted to one or more groups, as well as to individual users. Every group has a group type (defined below), as well as a list of users and member groups that belong to it.

Group Type Group Type

A group type is used to organize groups, and can only be created by users of type System Administrator. For example, the Region group type allows a designer to organize their sales teams by creating a different Region group for each sales team, for instance, Commercial West, Commercial East, Midwest.

Group types also define attributes that are shared across groups. For example, the group type Region might have a "regional VP" attribute. Then, each group of that group type would have a different value for the attribute, based on who that region's vice president is.

Integration Integration

An integration can be used to call external systems and web services from Appian. Integrations can be called in expressions or SAIL interfaces to query or modify data in external systems.

Interface Interface

An interface returns one or more SAIL components to display on a record view, Tempo report, or process form. This is the primary object that designers use to show user interfaces to application users.

Knowledge Center Knowledge Center

A knowledge center stores documents and document folders. They control the security of their contents, and provide a way for designers to organize document into logical hierarchies.

Process Report Process Report

A process report displays data from active Appian processes and tasks. For reports that display data from a variety of sources, see Report.

Process Model Process Model

A process model is the primary tool in Appian for describing a workflow. Designers graphically lay out the workflow, which may assign user tasks, manipulate data, post system events, or update other design objects. Process models are frequently used with record types to provide users with tools to act on the information shown by the record.

Query Rule Query Rule

A query rule is a defined query against a single data store entity. It returns an array of the values that match the parameters defined in the query rule. Designers may also use the a!queryentity() and queryrecord() system functions to perform similar queries. See Querying Data From an RDBMS to learn more about deciding which to use.

Record Type Record Type

A record type brings together all the data on a single topic and displays it in a series of record views. For example, a shipping company may have records for vehicles, customers, and locations. But it’s not just the most visible and long-lived concepts that work well as records—the shipping company may also have records for fleet maintenance, truck rentals, customer status, and purchase orders. That’s because records provide a centralized view of a given object, along with all of its connections to related records.

Attaching process models to record views as related actions allows users to immediately take action on the information shown in the record view.

Report Report

A report displays data from tasks, records, and other data sources in a single interface in Tempo for end users to view. Through the use of graphs, grids, pictures, and the dynamic behavior that SAIL offers, a report offers a high-level overview of aggregated data.

For reports that display data from Appian processes and tasks, see Process Report.

Site Site

A site is a simple and distraction-free user interface best suited for focused task workers. When working in a site, users can view a task report, follow task links, and submit tasks without seeing the five tab navigation bar shown in Tempo.


A Web API provides a way to expose data that is stored inside of Appian or is accessible by Appian to another system. Each Web API is an association between a URL and an expression. When a client makes an HTTP request to the given URL, the associated expression is executed and the result is returned to the client. This means that any data that is available inside an expression can be exposed to an external system via a Web API.