Applications

Applications contain specific types of data records, such as incidents, controls, policies, or assets. Through Application Builder, you can define the properties of applications, including the fields they contain and their layout, and automate actions within the application.

You can also group multiple applications into a solution, enabling end users to search against those application from a workspace.

For example, you can use an application to keep track of all your vendor information, and activity.

However, when onboarding new vendors, you may want to poll new vendors for details to add to your vendor application, in this case, consider a questionnaire.

On this page

Types of applications

Core applications

Core applications are preconfigured applications that Archer provides. They can be reconfigured to meet your needs, but are intended to give you a starting point and save you work.

On-demand applications

On-Demand Applications (ODAs) are applications that are built from scratch to support ancillary processes. An ODA allows administrators to create their own configurable application or use pre-built Archer Exchange offerings, which can leverage advanced workflow, notifications, reporting, access control capabilities and more. ODAs are not part of the standard Archer solutions and use cases and require additional licensing.

System applications

2 system applications, Task Management and Appointments, are included in every Archer deployment, regardless of which use cases you have licensed.

Leveled applications

You can create multiple data levels within an application. By organizing fields into levels, you can create master-detail record relationships within a single application. By linking records from 1 level to records at the level above or below it, you can create hierarchical applications.

The Policies application in the Policy Program Management use case is an example of a leveled application. It contains 3 levels of data: Policy, Area, and Section. Each record in the Area level is related back to a record in the Policy level, and each record in the Section level is related back to a record in the Area level, as shown in the associated diagram of the Policies application.

An application can have many levels, and each data level has its own distinct fields, as shown in the following figure. Do not create more than 4 data levels in an application.

Example of a parent application with multiple levels.

Use a leveled application to relate records in a child data level to 1 parent-level record. In the Policies application example, the record 8.3.3 Password Expiration in the Section data level can only relate back to record 8.3 Authentication in the Area level.

If you are considering a leveled application, but foresee child-level records relating back to more than 1 parent-level record, consider creating 2 applications instead and linking those applications with a cross-reference field.

Who can work with applications?

Through an access role, you must have the following rights to work with applications:

  • Configuration administrator of the application.
  • The appropriate CRUD access role settings to the Administration>Application Builder>Manage Applications page.

Full editing rights, as controlled by the access role, include: