Key Concepts

This page applies to developers, data stewards, and business users. It describes the common concepts used throughout Process HQ.

Attributes

An attribute is a characteristic of a case or event that provides additional context for the process, such as the cost of an event, the user who performed the event, or the location of a related customer. For example, in a Financial Customer Onboarding app, the customer's region might be a helpful attribute, so you can determine whether there are differences in how long a process takes for each region.

Fields in both case and event data are mapped to attributes when you submit your process data for analysis. These attributes help define or distinguish cases or events, and attribute values can be used as filters in process exploration and insight creation.

Business process

A business process represents a set of activities that your organization performs as a part of conducting business. Common business processes include receiving and fulfilling customer orders (order-to-cash), procuring goods from vendors (procure-to-pay), and onboarding new clients, but the process you want to analyze can be as unique as your business itself.

Your organization can be a rich source of data about your business processes. IT systems typically track process activities, including when they happen, who performed them, and other characteristics. For example, in a retail organization, this might include information about when an order is received, a product is delivered, a customer is contacted, a payment is made, and more.

In Process HQ, the business process becomes a process, that is, a unit of data that can be analyzed to uncover actionable insights.

Case data and event data

In process insights, case data is an umbrella term that represents the combination of data from the case record type and its related record types.

For example, in a purchase order process, your case record type would be the Order record type. The Order record type likely has a few relationships configured, like a relationship to the Order Items record type and Customers record type.

Data stewards can use the order data and its related data to build a more comprehensive understanding of the entire order process: the orders themselves, the number of items included in each order, and which customer submitted each order.

In process insights, event data is an umbrella term that represents the combination of data from the event history record type and its related record types.

For example, as a best practice, you should store the list of activities that can occur in a process in a separate, related record type. If you've configured the record events capability, this record type is called the event type lookup record type.

Case record type and event history record type

Both cases and events are represented in Appian as records. At minimum, Process HQ requires a case record type containing one record for each case, and an event history record type for events. These record types must have data sync enabled and there must be a one-to-many relationship between the case and event history record types.

Let's look at a basic example of record types for the customer onboarding process. The cases are stored in the Onboarding Case record type and the events are in the Onboarding Event History record type.

As mentioned earlier, each event (or row in the Onboarding Event History record type) must have at least three fields, in addition to a primary key: a field relating it to a case, a field to capture the activity performed, and a timestamp.

Other fields in the case record type and the event history record type can be used by Process HQ for filtering, sorting, and aggregating your data during analysis. Process HQ can also access data from related record types, provided that they have data sync enabled.

Data stewards will use this collection of data to add processes in Process HQ. Process HQ then analyzes the cases and events to generate a processes diagram and discover patterns based on case and event attributes.

Cases, activities, events

Process HQ conceptualizes business processes using cases, activities, and events. To understand what these terms mean, let's look at a few examples.

First, let's imagine a company with a business process for onboarding new customers. This process involves the following steps:

• An application is received.
• An initial review is performed.
• Documents are verified.
• The customer account is created.
• The customer is notified.

Each of these steps in the business process is referred to as an activity. Activities are the real-world tasks or actions that occur as part of a business process. In this example, each customer application that goes through this process is represented by a case. Cases are specific occurrences of a business process.

Let's look at another example for managing customer support tickets. In this business process:

• A support ticket is submitted.
• The ticket is categorized.
• The ticket is assigned.
• The issue is addressed.
• The submitter is notified.

Here, the support tickets are cases, and each step in the process is an activity.

In both examples, cases move through a business process as activities are completed. Each time an activity is completed for a given case, that is considered an event.

At minimum, events have three key components:

• The activity that occurred.
• The case for which the activity occurred.
• A timestamp for when the activity occurred for that case.

Dashboards

A dashboard allows business users to tell a complete story with your data. A dashboard can combine your custom reports, reports shared with you, and any process KPIs you can access, so that you have a comprehensive view of your organization's data.

Datasets

Developers working with Appian's data fabric are familiar with the record type and how relationships and record type security let you access data from the record type and its related record types. For business users, we use datasets to represent this same capability so they don't need as much familiarity with the technical details of your data fabric.

Each dataset is made up of a record type and its one-to-one and many-to-one related record types. For example, the image below illustrates the Customers dataset, where the Customer record type is the base record type. Based on the one-to-one and many-to-one relationships configured on the Customer record type, this dataset would include data from the Customers, Districts, Addresses, and Credit Cards record types.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

A dataset will not include data from one-to-many relationships. So if the Customer record type has a one-to-many relationship to the Order record type, it would not appear in the Customers dataset. Instead, a user could explore order and customer data together using the Orders dataset, so long as the Order record type has a relationship to the Customer record type.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Duration

One of the primary ways to track process success is measuring how long a process (or some part of the process) takes to complete. This measurement is referred to as the duration.

You can measure:

• Case duration: How long completing all the activities in a case takes collectively.
• Sequence duration: How long completing a sequence takes.
• Activity duration: How long completing an activity takes.

Occurrences

Process HQ uses your data to automatically identify any sequences, repetitions, and activities in your process. We call these process parts. Each time a process part occurs in a case, we call it an occurrence. Process HQ lets you examine how long occurrences take, as well as how often occurrences take place, so you can understand and improve your process.

Reports

A report empowers business users to independently explore and analyze record data curated by developers. The self-service report creation framework offers a selection of standard visualization formats, along with easy-to-configure filters and interactive elements.

You can share a report with colleagues in stand-alone form—or as part of a comprehensive dashboard.

Sequences

A sequence represents the flow from one activity to another activity.

The first activity in the sequence is known as the start activity. The second activity is known as the end activity.

In a direct sequence, the start activity is immediately followed by the end activity. The direct sequence is known as a repetition if the sequence starts and ends with the same activity. Typically, repetitions can be eliminated to reduce case duration.

In an indirect sequence, other activities can occur between the start activity and the end activity. The indirect sequence is known as a loop if the end activity for the sequence returns to a previous activity in the process flow. A loop may represent an intentional aspect of your workflow, or it may represent rework that you can potentially eliminate to reduce case duration.

Feedback