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. This page contains information about the application object. For information on designing applications, see Application Designer.
The table below describes application properties.
|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.|
Refer to the annotated screenshot above when reading about each of the features listed below:
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:
If you are updating an existing solution, use a patch.
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.
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:
Users can add the following configurations to fields.
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:
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:
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.
The News tab is used to post messages to users of an application.
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.
A report is generated for each application, containing four charts and a records grid.
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.
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.
|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.