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:
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:
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.
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.
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.
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:
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.
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.
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.
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.
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:
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.
A folder contains objects; any object in a folder can only be in one folder. There are three types of folders:
Other kinds of design objects are not stored in folders.
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.
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.
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.
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.
A process report displays data from active Appian processes and tasks. For reports that display data from a variety of sources, see Report.
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.
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.
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.
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.
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.