This article provides guidance on how to create and manage your applications in Appian. An application is a collection of objects that represents a business solution. An application functionally groups design objects together to form the user interfaces, logic, processes, and data your users will interact with while doing work in Appian. For information on designing applications, see Application Designer.


The table below describes application properties.

Property Name Description
Name The maximum length of the name is 255 characters. The names of published application are visible to users in Tempo in the Actions tab and from the avatar menu under Settings > News.
Description The maximum length of the description is 2000 characters. Application descriptions are not visible to users in Tempo.
Last Modified Consists of a user name and timestamp that is updated whenever the application is updated. Updating the objects associated with an application does not change this timestamp, though adding or removing objects does.
Published Determines whether the application's feeds and actions are visible in Tempo. A published application's name is visible in Tempo when it has feeds or actions.
Actions A list of process models that this application exposes in Tempo for users to start from the Actions tab.

Applications are accessed in the Application Designer, in the Appian Designer environment.

Refer to the annotated screenshot above when reading about each of the features listed below:

  1. Create from Scratch or Create Using Application Builder
  2. Import and Export
  3. Security
  4. Delete

Create from Scratch

Creating an application from scratch only requires a name, though a description is recommended. Creating an application immediately navigates you into the details view for that app. New applications are unpublished by default and contain no objects. To start with simple functionality as a base for development, create the application using the builder.

We recommend creating a dedicated application for every business solution. For instance, Customer Relationship Management (CRM) and Sales Opportunities would be different applications.

You should also create an application for each collection of objects that you intend to reuse across applications, such as a Common Objects application that contains utility rules, icons, and templates.

Finally, the values of some constants are specific to each environment. For instance, while building your application in your development environment, you set the ESCALATION_DEADLINE constant's value to one minute to facilitate testing of escalations. When deploying to your production environment, however, your constant should have the actual business value for time until escalating a process. For that reason, we recommend you keep environment-specific constants in a separate application.

Each of these application types could apply to the same project. If your first business solution was Customer Relationship Management, then your apps list might look as follows when you were done developing it:

  • CRM
  • Common Objects Library
  • Environment-Specific Constants

If you are updating an existing solution, use a patch.

Create Using Application Builder

You can also use a guided set of screens to generate an application with a base set of data-centric functionality. Before launching the application builder, choose a data source where tables will be generated for the new application. Then click Continue.

Creating the Application

The Create Application form walks users through a few simple steps and uses their input to generate the application. The builder has four steps:


On the first page, users name and describe their application.

Each app stores data in the form of Records in Tempo. We collect the singular and plural name not just because the record type requires them, but also so that we can name and describe other parts of the application in sensible ways. For example, an empty grid in Tempo would say that there are "No (plural entry name) available."

We use the first letter of each word in the application name to generate a prefix for the design objects in the application. For example, a rule in the Support Ticket Management application might be called "STM_GetSupportTicketById". This prefix is guaranteed to be unique among all Quick Apps and generated apps on the system.


On this page, users specify the fields of information they want to capture for each record. This serves as both data and interface design for the app, and provides the core of its unique design.

Users can create fields of the following types:

  • Text
  • Number (Decimal)
  • Paragraph
  • Date
  • Date and Time
  • Single selection from list (Dropdown, with user-specified text options)
  • Multiple selection from list (Checkbox, with user-specified text options)
  • Record (Record Picker, configured to a single record type)
  • User

Users can add the following configurations to fields.

  • Field requiredness
  • Instructional text to display below the field
  • Help tooltip to display next to the field label
  • Placeholder text to display within the field (not available for all field types)

Configurations display on forms, but not on the record dashboard.

Three fields are pre-populated and required for every application: Title, Status, and Priority.

Configurations can be added to these fields just like other fields. In addition, the label of the Title field, and the options of the Status field, may be changed. The Priority options are not editable because we have specific icons associated with each one.

A Preview Form option is available on this page. It shows how the currently configured values will manifest in the Action and Records of the completed application. Specifically, it offers a preview of the start form of the Action, and the Summary view of the record type. Users can use this to help design their application to look exactly as they want it to, without having to create it first and then Update it to make changes.

Each field added on this page results in a new field on the main CDT of the application, with the following details:

  • Text and Paragraph fields are each a Text field on the CDT, but the resulting database column has its length constraint increased to 4000 characters for Paragraph fields. (For both Text and Paragraph fields, the interfaces generated enforce the database limit on character count, to prevent errors.)
  • Number, Date, and Date and Time fields are each made into a CDT field of the same type, with no other special configurations.
  • Single and Multiple selection fields generate additional CDTs that are nested from the main CDT. These nested CDTs always have fields for the ID, value, and order of the selection options, as well as whether they are active or not.
  • Record fields store the identifier of the selected record, which means that they are either a Text or Integer field on the CDT, depending on the type of the identifier of the selected record type.
  • User fields are a Text field on the CDT.


On this page, users specify the people who should use the application.

Collaborators have access to all application functionality.

The people selected at this step are added as members of a group, which is created to secure application activity to.

When you click Create Application on this page, your application will be created! Please allow up to a minute for generation of the application.


Once your application has been generated, the final page of the form will load. Links to your new functionality will appear here:

  • An action to create new records
  • The record list
  • A report on all records

Functionality of each Application

Each application is published immediately, and provides record-centric functionality to its users. Creating, viewing, modifying, and collaborating around the data in your records makes up the bulk of work enabled by the application's design. Details on each section of functionality are below.


Each application adds a single Action to the Actions tab, which allows users in the Collaborators group to create new records. This start form will match the preview available while creating the application.


Each application has a record type that is the central hub for work done in the app.

  • Every Collaborator in your application can create, view, update, and delete any record in your app. Creation occurs from the Actions tab, while the other actions can be taken directly from the record's Summary view.
  • Each record contains an Activity History view. This view describes every action ever taken on or from this record. This includes creation, updates, file uploads and deletions, sending, completing, and skipping tasks, and sending messages. You can search the grid for specific updates as well as filter by user.
  • The Summary view also contains a grid of any currently-open tasks for the record. Once completed, those tasks are still recorded in the Activity History.


The News tab is used to post messages to users of an application.

  • Users can send a message from any record through a related action on the Summary view, and may add an attachment.
  • The message is posted to News as a locked message to the Collaborators group.
  • It is tagged with the record, and so is also available in the News view of that record.


For targeted alerts and requests, tasks can be sent from the record to any user on the system through a related action on the Summary view.

  • If the assignee is not already in the Collaborators group, the user sending the task will be informed of that and asked to confirm that they intend to send the task to that user. If and when they do, that user is added to the Collaborators group.
  • Deadlines can be set by the user who enters the task. The task remains available after the deadline, but displays as overdue in the task list.
  • Task forms display information about the record they were sent from and link to them. The only field to fill out on a task form is comments responding to the user who sent the task.
  • When a task is completed or skipped, an email is sent to the user who sent the task to notify them.


A report is generated for each application, containing four charts and a records grid.

  • The four charts are:
    • Top Record Creators: A bar chart showing the number of records created by the five users who have created the most records.
    • Record Creation Trends: A line chart showing how many records were created in each of the last six months.
    • Records by Status: A pie chart showing the number of records in each Status.
    • Records by Priority: A pie chart showing the number of records in each Priority.
  • The records grid shows a list of records on the system. It has up to eight columns showing the first eight fields in the application. The Title field is linked to the record, and other fields display as they do on the record dashboard.
    • A text field above the grid allows users to search records by any Text, Number, Paragraph, or Single Selection from list fields that appear in the records grid.
  • Each chart is clickable and filters the records grid below. That filter displays in a rich text field above the grid.
    • For example, clicking on a Status option will filter the records grid to display only records that are in that Status. The rich text field above the grid displays that filter and allows clearing it and the search field.
    • Filters can stack, so that all four charts can filter the grid at the same time, if desired.


  • All application activity is secured to the Collaborators group.
  • Specifically, the Collaborators group is set as Viewers of most of the application objects, and as Editors in the document hierarchy so that they can successfully upload documents.
  • An Administrators group is generated for the application and set as Administrators of all objects. The initial membership of the group is the user who generates the application.


  • Each application is created in the locale of the user who created it. This means that any strings the system generates or configures in creating the application will be set to that locale, but user-provided strings will be displayed exactly as provided.
    • For example, in an application for Support Ticket Management, the Action will be called New Support Ticket. The word "New" is provided by the system and will be provided in the current user's locale, while "Support Ticket" is the entry name as provided by the user, and so the system uses it exactly as entered.
    • For this reason, we highly recommend that users build applications using the language their profile is currently set to. Otherwise, the application will be created with a mix of languages.
  • These applications are internationalized on creation, not at runtime, and will display the same values to every user.

Import and Export

Exporting an application compresses it and its associated objects into a package that can be imported on other environments. This is typically done to move work from a development environment into a staging or production environment.

The links between related objects in the application are preserved when importing, but related objects are not exported by default unless they are already in the application. The Application Designer allows you to scan for missing precedents and add them to your application before export to ensure that your work functions properly when imported into a new environment.

Both export and import create an event in News Feed. For imports, this event has the import log attached. Events for exports have both the export log and the exported package attached. By default, the user performing the export or import is the only viewer of the post, but they can add other users to it to share the logs or export package.

Applications that contain many objects may take a long time to export. You can navigate away or log out while the export is in progress, and the event will appear in the News Feed when the export is completed.

To combine multiple applications into the same export package, select all the applications from the applications list that you want to export together. These applications must all be on the same page of the applications list.

Deploying applications is covered in detail here.

Application Security

New applications created in Appian Designer add the creating user to the role map with administrator permissions. Having permissions to an application does not give the designer permissions to the objects associated with an application. Users in Tempo must be at least application viewers to see the actions or feeds of a published application.

Application roles and the permissions each one gives to the application object are summarized below.

Actions Administrator Editor Viewer Deny
See application feeds or actions in Tempo Yes Yes Yes No
Export the application Yes Yes Yes No
View and filter missing precedents Yes Yes Yes No
View application properties and contents Yes Yes Yes No
Update filters in missing precedents Yes Yes No No
Update application properties and contents Yes Yes No No
Update application properties and contents via import Yes Yes No No
Import a patch Yes Yes No No
View application security Yes Yes No No
Update application security Yes No No No
Update application security via import Yes No No No
Delete the application Yes No No No


Applications can be deleted like other design objects, and may be deleted in bulk. Deleting an application does not delete any of its objects (since they are associated with the application but not contained within it).

Deleted applications are removed from the system and cannot be restored.