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 a 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 your 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 is represented by a process that can be analyzed to uncover actionable insights.

Case data and event data

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.

Similarly, 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 record events, this 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.

A process requires two essential record types:

• A case record type containing one record for each case.
• An event history record type containing one record for each event.

Both must be synced record types, and you must configure 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.

Each event (or row in the Onboarding Event History record type) must have the following fields:

• A primary key field.
• A field relating an event to a case.
• A field to capture the activity performed.
• 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 process data during analysis. You can also include data from other related record types in your process, so long as they have optimized data access.

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 record types and how relationships and record type security let you access data from a 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.

A dataset consists of a base record type and its one-to-one and many-to-one related record types. For example, if a Customer record type has one-to-one or many-to-one relationships to the Districts, Addresses, and Credit Cards record types, then the Customers dataset includes fields from all four record types.

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

A dataset does not include data from one-to-many relationships. So, if a 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, as long as the Order record type has a relationship to the Customer record type.

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

You can build reports from datasets in Process HQ, then add those reports to a dashboard.

Related datasets

Related datasets share data with the current dataset. When you build a report, you can access fields from both the primary and related datasets. Related datasets are also independently accessible in the Data Catalog.

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

Processes

A process is an object you create from your organization's data to represent a particular business process.

Processes combine data from a case record type, an event history record type, and related record types that contain relevant data.

For example, in a Financial Customer Onboarding app, you might have a case record type called Onboarding Case, and an event history record type called Onboarding Event History. Important related record types could include Customer, Region, and Onboarding Event Type.

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

Record fields that you include in your process are called attributes.

One Process HQ analyzes a process, you can explore and drill down on the results of the analysis to understand how well it's performing. Measure and track duration and occurrences of cases, activities, and sequences with KPIs, and use the process as the data source for a report.

Reports

Reports empower business users to independently explore and analyze business data. You can build reports from datasets and processes, and leverage AI Copilot to discover areas for improvement. You can customize reports with different visualizations, easy-to-configure filters, and useful interactive elements.

You can share reports with colleagues and add them to 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