This page applies to developers, data stewards, and business users. It describes the common concepts used throughout process insights.
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.
Note: If you're used to working with process models in Appian Designer, be aware that we're using the word process in a different way here. A business process is not the equivalent of a process model. A business process can, in fact, be made up multiple process models. For example, an order fulfillment process may use data collected from the Create Order process model, the Order Approval process model, and the Order Shipping process model.
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:
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:
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:
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.
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.
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 can be used as filters in process exploration and investigation.
A sequence represents the flow from one activity to another activity.
The first activity in the sequence is known as the starting activity. The second activity is known as the ending activity.
In a direct sequence, the ending activity takes place immediately after the starting 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 starting activity and the ending 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.
Key Concepts
