This page applies to developers. It describes how to connect to the source of process data.
To successfully analyze how your business processes work, you'll first need to connect to the data about those processes. Appian's data fabric capability lets you easily connect to that data regardless of where your process data is stored—whether that's a relational database, a web service, or even static files of comma-separated values.
The sections in this page describe the data model to use for your process data and the configuration steps you'll need to connect to your process data.
After you connect to your process data, review the different data preparations you can perform to prepare that data for process analysis.
To be compatible with process insights, process data must be stored in synced record types. These record types must have specific fields and relationships configured to use the data in process insights.
To be accessible in Process HQ, your process data must be stored in record types with data sync enabled.
You must have at least two record types containing the primary data about your process:
For example, in an Order Management app, the Order record type stores information about the order itself, such as the name of the customer who placed the order, and the Order Event History record type stores the details of how and when your organization received, acknowledged, and fulfilled the order.
Those two record types may represent all you need to know about your orders, but you may also have captured data in additional record types that provide more context for understanding the process.
For example, in the Order Management app, you might want to know more about the customer who placed the order, such as what industry the customer belongs to. That data would be stored in a Customer record type, which can also be accessed in Process HQ.
When creating your synced record types, keep the following in mind:
Store lookup data in a separate record type, so those static values stay consistent across your data.
For example, it's a best practice to store the list of activities that can occur in a process in a separate, related record type. If you've configured record events, this related record type is called the Event Type Lookup record type.
The fields in your record types become part of a process known as attributes. Attributes are characteristics of a case or event in process data that provide additional context about a case or event.
To ensure there are consistent attributes to analyze in a process, the case record type and event history record have a few required fields.
In the case record type, there is only one required field:
Required Field |
Data Type |
Description |
|---|---|---|
Case ID |
Number (Integer) |
The unique identifier for the specific occurrence of the business process. This will be the field used to create the relationship between the case and event history record types. Typically, this field is the primary key. |
In the event history record type, required fields include:
Required Field |
Data Type |
Description |
|---|---|---|
Case ID |
Number (Integer) |
The unique identifier for the specific occurrence of the business process. This will be the field used to create the relationship between the case and event history record types. The case ID must be a unique field. Typically, this field is the primary key on the case record type and a foreign key on the event history record type. |
Activity |
Number (Integer) or Text |
The real-world action or task that occurs as part of the business process. If you follow best practices, this field would be of type Number (Integer) that references the activity in a lookup record type. However, this field can alternatively be of type Text and contain the exact activity names, like Created Order or Filled Order. Activities should have short, human-readable names, and must be stored in a single field. If your activity data doesn't meet these conditions, additional data preparation is required. |
Start or End |
Date Time |
The date and time that the event either started or ended. This value is used to calculate case duration in process insights. If you've configured record events, this field represents an end timestamp. For more information about event timestamps, see Write events at the right time. |
When selecting and configuring fields, keep the following in mind:
Record type relationships provide a fast and easy way to connect and reference related data. By adding relationships from your case record type and event history record type to related record types, you can easily analyze data from multiple sources in process insights.
The relationships between the case, event, and associated record types determine what data can be included for analysis in a process.
Your case record type must have a one-to-many relationship to your event history record type, so that the individual events can be analyzed as a single process. For example, in an Order app, the Order record type should have a one-to-many relationship to the Order Event History record type.
Tip: When adding relationships, provide user-friendly relationship names, so data stewards can easily recognize the relationships between record types when adding or editing a process.
When creating relationships, keep in mind that data stewards can only select fields from a one-to-one or many-to-one relationship when adding a process. They cannot select fields from a one-to-many relationship.
For example, in a purchase order process, the Order record type (in process insights terms, the case record type) could have the following relationships:
When you create your synced record types, you'll need to connect to your process data—whether's it in a database, salesforce, a different web service, or a CSV file.
The sections below describe how to connect a record type to the source of your existing process data.
One of the most common ways to store process data is in a database. Whether it's in the out-of-the-box Appian Cloud database or in another supported database, it's easy to connect to that data so you can use it as the source of your record type.
If you haven't captured process data yet, you can start collecting that data by configuring record events in your applications. See an example of how you can configure record events to capture process data.
If your data is already in Appian, but it's available in record types without data sync enabled (unsynced record types), or it's only in custom data types (CDTs) and data store entities (DSEs), you'll need to create new synced record types to access this data in Process HQ.
Note: Do not enable data sync on existing record types. Doing so will create new UUIDs for your record fields, which will cause any existing field referenced to break.
To connect to process data in a database, you typically only need one or two objects:
See specific examples of connecting and preparing process data from a database:
You can connect to process data via any web service with an HTTP interface. Appian provides out-of-the-box connectors that support a wide variety of authentication types.
You may also want to ask your system administrator to install the connected system plug-ins from the AppMarket. These plug-ins can simplify integrations by abstracting a third-party API.
To connect to process data in a web service, you'll need to create a small number of objects in Appian Designer:
See a specific example of connecting and preparing process data from a web service:
You can easily connect to process data from Salesforce using the out-of-the-box connector.
Salesforce objects map easily to record types. For example, you can use the Field History table of your objects to construct an event history.
To connect to process data in a web service, you'll need to create a few objects in Appian Designer:
See a specific example of connecting and preparing process data from Salesforce:
If your process data is stored in a system that cannot be accessed via an API, you can typically export the data as a file of comma-separated values (CSV).
To bring that data into Appian's data fabric, you can use the Excel Tools plug-in from the AppMarket. Ask your system administrator to add this plug-in to your environment.
At a minimum, you will need two CSV files, one for cases and one for event history. Prepare the data in Microsoft Excel to meet the requirements of the plug-in. If each file does not have a unique ID column, add a blank column to the file. This blank column will be used later as the ID field in the record type.
Then, to import these files, you'll create a small number of standard objects in Appian Designer:
A case record type and an event history record type connected to database tables that will ultimately store the process data. The fields you add to each record type must correspond to each column in the corresponding CSV file, and the field names must be exactly the same as the CSV columns.
For each CSV file:
To complete the capture of the CSV data, you'll need to run the process model to write the data from the files to the database, trigger a manual full sync on the case and event history record types, and create a one-to-many relationship from the case record type to the event history record type.
See a specific example of connecting and preparing process data from CSV files: Example: Comma-separated values (CSV).
Connect to Process Data
