Creating Applications


Create an Application

This lesson from the Introduction to Applications course walks you through the basic steps of creating a new application.

This page explains what an application is, and the two ways to create an Appian application:

When using the Application Builders, Designers will have two options for application: Basic and Full.

For specific information about working in the Appian Designer space, see Applications.

What's an Application

Applications are essentially a collection of objects that make up a business solution or function. We recommend creating a dedicated application for every business solution. For instance, Customer Relationship Management (CRM) and Sales Opportunities would be different applications.

In addition to creating applications to serve business functions, 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.

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

When updating an existing solution, use a patch.

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 created from scratch are unpublished by default and contain no objects.

An application is, in itself, an object whose functionality affects what is seen in Tempo (sites or embedded interface users are not affected). Exposed application functionality is found on the Actions tab of Tempo. This section covers the steps necessary to expose application functionality to Tempo if you are creating an application from scratch.

How to Get Your Actions in Tempo

Application actions can be created: manually from the application properties menu, saved as an application action via an interface, and through the application builder. In this page, we will only discuss creating an Action and publishing it from scratch.

To learn more about creating applications in general, check out the Application Building Tutorial.

This section is focuses on application exposure in Tempo. The concept of actions in Sites or Embedded Interfaces differ from Tempo, and do not utilize application actions.

Manually Creating an Action

As long as our application contains an ‘actionable’ process model we can create an action. By actionable, we need the process model to contain a start form, user input task, or some other attended node that will allow a user to interact with the model. This is a logical limitation rather than a functional one… we want actions that allow the user to interact with that process.


When we create actions and publish applications from scratch, we are using the application’s properties to manually define our actions.

Applications actions need names, descriptions, and process models to start. While these applications can be created in any order, they will be ordered alphabetically in Tempo.

Publishing Applications

Application can be in a published or unpublished state. This feature lets administrators expose or hide application actions from users in Tempo.

When published its application icon in Appian Designer will appear red. A published application will appear as a filter on the Actions tab of Tempo.


Setting Application Security

Whichever method is used to create and publish an application, security should still be considered. In order for users to see the application and application actions they will need at least View access to the application and process model.

For more information on application security, see Securing Applications.

Create Using Application Builder

The Application Builder is a feature of Appian Designer that creates an application with pre-defined set of objects. There are two different types: basic and full. Both sets of templates use the same paradigm to create applications, just with a different level of functionality.

Creating a Basic Application

A basic template from the application builder creates only the objects necessary to create, view, update, and delete the records in your app.

This template is especially useful if you want to jump start a brand new application. Instead of creating the base objects from scratch, this template will give you a basic application in a few minutes.

Creating a Full Application

A full template has all of the record functionality of a basic application, and also includes functionality for: audit history, collaboration, document management, task assignment, and reporting.

This template is useful if you had planned to implement this functionality in your application anyway; otherwise, a basic application will likely be simpler to enhance and build out.

The Application Builder Wizard

After the template type and datasource is selected from the Create New Application dialog, the Application Builder will launch. The Application Builder is a four step wizard that will guide designers through the application creation process. Depending on whether a basic or full application was selected, the defaults within the Application Builder will change.


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.

When using the full template, three fields are pre-populated: Title, Status, and Priority. Of these, only Title is required (however, the name can be changed). When using the basic template, only the Title field is pre-populated.

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:

  • For both Text and Paragraph fields, the interfaces generated enforce the database limit on character count, to prevent errors.
  • Paragraph fields are stored as additional lookup CDTs with a foreign key relationship made between it and the main CDT.
  • 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. Additionally, for full template applications, designers can choose whether to make this a site-based application (default) or exposed through Tempo.

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.

The application builder, will default for the full template to a sites-based application.

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.

Features of an Application Builder App

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.

Records for basic and full template applications will include:

  • A Summary view with all relevant record data.
  • View, update, and delete capabilities for any record in your app.
    • Creation occurs from the Actions tab.

For full templates only, each record will also contain:

  • 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, skipping tasks, and sending messages. You can search the grid for specific updates as well as filter by user.
  • Related Actions for task assignment and sending a message to someone about this record.
  • The Summary view also contains a grid of any currently-open tasks for the record.
    • Once completed, those tasks are recorded in the Activity History.

Tasks (Full Template Only)

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.

Reports (Full Template Only)

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.

News (Full Template/Non-Site Only)

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.

Sites (Full Template Only)

A site can be created using a full template.


For pages will be added to the site:

  • Record- The first page is the application's record and will be named after the plural record name field in the application builder wizard.
  • New - Lets users create a new record.
  • Trends - Reporting metrics on record data.
  • My Tasks - Tasks assigned to you from the Send Task related action in the record.


  • 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.

For more information on application security, see Securing Applications.


  • 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.
Open in Github

On This Page