Applications contain a set of objects that function together to meet one or several business use cases. Applications allow these objects to be transported from one environment to another.
Each design object provides a specific piece of functionality, and each application comprises many objects grouped by common purpose. Technically, Applications do not contain these objects, but simply have a list of objects that are associated with them. The objects view shows a list of objects ignoring the Application association. The following sections describe each Appian object.
Records, Data Stores and Custom Data Types are all data-centric object. Their icons will appear orange in the Application and Object view.
As opposed to a primitive or system data type a custom data type (CDT) is a designer-defined data structure. DTs allow designers to create a logical grouping of related data that can then be used by other objects to share data. Data can be shared internally, for instance between an Interface and Process Model, or externally, between an Expression Rule and Data Store.
Because a data type will always be used in context of another object, it does not have individual security settings.
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 define the structure of the data entity being stored.
A record type brings together all the data on a single topic and displays it in a series of record views. Records provide a centralized view of a given business function, 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.
Process Models and Process Reports can be considered process centric. Process Models define how a process will function while Process Reports allow users access to data from the process.
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 process report displays data from active and recently completed processes and tasks. Designers can choose to create process reports from scratch or pick from one of several dozen of out-of-the-box report templates.
Objects that are primarily involved with interactive user displays fall into this category. Interfaces, Report, and Sites are all objects are created in order for users to interact with the Application. Although, Record Types provide user interaction functionality, the object also is a query-able source of data.
An interface is an object that returns one or more 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 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][SAIL_Design.md] offers, a report offers a high-level overview of aggregated data.
A site is a customizable user interface where Designer can create focused work environments for their user. When working in a site, users can view a task report, submit tasks, and kick of new actions, all without seeing the five tab navigation bar shown in Tempo.
Rule based objects are used in Expression to reference specific values and perform complex operations or queries. Expression Rules, Decisions, Constants, and Query Rules are all considered rule-based objects.
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.
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 constant holds a single user-defined value or 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 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.
Whenever an application needs to interact with a third-party system or vice versa, designers will use as many as three different type of objects: an Integration, a Connected System, and a Web API
An integration can be used to call external systems and web services from Appian. Integrations can be called in expressions, interfaces, and process models to query or modify data in external systems. They can inherit connection details and logo images from a connected system.
A connected system represents an external system or service that is integrated with Appian, for example, Microsoft Sharepoint, MuleSoft, or a custom web service. Connected systems have logos which can be customized to help visually identify the system or service.
A connected system allows you to define the details of a connection once and then use those details in one or more integrations. With a connected system, if a value needs to be updated in the future, for example if a password changes, it only needs to be updated in one location. Connected systems also make it easy to manage connections that change as you deploy integrations from development to testing and then production.
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.
Appian managed object permissions through group membership and system roles. Groups and Group Types are the objects that support security and permissions throughout the Application
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.
Appian has a robust content management framework that allows designers to store and organize Application content. For document management, there are three specific objects involved: Knowledge Centers, Document Folders, and Documents. Additionally, process model and rule folders exist to assist in the organization of these objects.
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.
Folders allow you to organize your application content and centralize security settings. Design objects and documents can only belong to one folder at a time.
You can create folders within folders for multiple levels of organization.
Items in a folder (including sub-folders) are listed in both the application view and the folder view.
Security settings for the folder apply to all items within it (with the exception of Process Model Folders).
Folders created within other folders by default inherit security from their parent folder. Edit the security of the child folder to change this option: Inherit security from parent.
There are four types of folders to choose from (Rule, Process Model, Document, and Knowledge Center).
Rule folders can store the following design object types:
Process model folders can only store process models or other process model folders.
Security set for a process model folder is not applied to its contents.
Document folders can contain documents or other document folders.
Document folders can only be created within a knowledge center or within another document folder.
A knowledge center stores documents and document folders.
A feed object is created to support notifications on News in Sites or Tempo.
A feed is a channel for delivering content to the News Feed in Tempo or Sites. Every post or event in the News Feed that isn't directly created by a user has a feed associated with it. Generally, designers use a separate feed for each topic for which their application creates events or comments.
On This Page