This guide provides guidance and recommendations for designing Appian applications that can provide meaningful business insight when mined using Appian Process Mining.
This guide covers the following topics:
New in Appian 23.2. Appian Record events allow you to seamlessly track who takes action on your records and when, with minimal configuration on your part. This feature greatly reduce the time and complexity needed to create business events.
It is highly recommended to use the Record events feature over other custom built alternatives.
Before you start using process mining to extract meaningful insights from your Appian applications, a brief background on the discipline of process mining is recommended.
The steps necessary to mine an Appian application are depicted below.
When planning your events, remember that events can be “anything” that happens in a process. You should consider capturing enough events that you can provide a realistic and faithful picture of the processes' timelines and how they are executed.
When developing an Appian application, it is common practice to capture:
The level of granularity for the events is application specific and based on your business requirements. At a minimum, we recommend capturing one event per user task or wizard of related tasks. Additional events could be captured for system-to-system integrations or for tasks performed in third-party systems; especially when these are asynchronous or variable in duration.
Use one or more of the following common patterns to capture your events:
Refer to the section “Event Data Capture in your Appian Applications” for details on patterns used to model and persist events.
Certain minimum data requirements must be met in order to create an event log and mine a business process. Refer to the Appian Process Mining documentation for more information: Data Sets and Event Logs.
Import application data (events and business entity data) into Mining Prep using one of the following methods:
Using Mining Prep, aggregate and transform your application data to create a “flat” representation of processes timelines. This may include:
When you're finished with transformations, load the cleaned data to process mining for modeling and analysis.
For example:
After event data is loaded into Process Mining, the discovered model visualization displays the existing process. Use the case and event data to slice and dice the activities and discover meaningful insights.
Additional information about Steps 2 to 4 is available in the Appian documentation page Process Mining, Start to Finish.
This section describes 3 design patterns for capturing event data as part of your Appian applications:
These patterns can be used independently or together within the same Appian application in order to capture event data. The table below summarizes their main characteristics.
Record Event
Audit History Pattern
Process Task Data Pattern
Events are configured for the main business record types in the application
Audit data can represent any tasks, business events or business milestones as designed in the application
Audit data is limited to user input tasks. All events generated are tied to users completing tasks
Events are created automatically by Appian when you use the Write Records smart service
Audit data is created manually by populating a CDT and persisting the values in a database table
Audit data is created automatically by Appian when user input tasks are executed. A process model retrieves it using a Process Task Report and persists it in a database table
Events generated are populated by Appian based on the event type that you provide
Event attributes can be generated using expressions rules
The Case ID attribute and other event attributes must be designed as process variables in all process models containing user input tasks to mine
Additional events can be created using the Record event guided user experience in the Record Type designer
Additional events require development to be generated and persisted in the database
Additional events from new applications or new tasks can be captured using this pattern without additional code
Real life implementations of these patterns include:
Use these patterns as starting points for designing tailored solutions that work for your domain model and your requirements.
The Record events feature was released in Appian 23.2.
Record events allow you to seamlessly track who takes action on your records and when, with minimal configuration on your part. You’re able to generate and capture data about your processes within your standard Appian workflows.
The Audit History Pattern relies on audit data manually created and saved into a database to create Process Mining events.
The Audit History application (available in the Appian AppMarket) showcases an example of this pattern. The audit data is created by a script task and inserted into a dedicated database table.
The CDT named “AH_AuditHistory” represents an audit history entry/row. It contains the necessary data points to generate the key attributes needed for process mining such as the case identifier, timestamps and activity.
To Mine an application that uses the Audit History pattern, map the data stored by the CDT “AH_AuditHistory” to the Process Mining event log attributes.
Process Mining Log Attribute
Audit History Data
Case ID
Use the combination of the fields “recordId” and “recordType” or a unique business identifier if available.
Activity
Use the field “action”
Start Date
Use the field “startTimestamp”
End Date
Use the field “endTimestamp”
When using this pattern, you should:
The Process Task Data pattern relies on the task metrics generated by the Appian platform to create Process Mining events. To use this pattern, save the task metrics and additional contextual data into the database; to be later imported into Mining Prep.
In order to extract this process task data, use:
1. A task report that gets the task data for a set of process models or for the entire platform
2. A Custom Data Type (CDT) that maps to the data from the task report
3. A process model - running on a daily timer - that executes the task report, stores the outputs as a list of CDTs and persists this data into a database
To Mine an application that uses process task data, map the data stored in the process task table to the Process Mining event log attributes:
Process Task Data
Use the attribute CASE_ID
Do not use the process model ID. Use a business attribute that is unique to each case/business entity. This value is configured as pv!processVariableName in the report.
Use the attribute TASK_NAME.
The static task name must follow the recommendations related to the event activity name as mentioned in this document.
Use the attribute START_TIME
Use the attribute END_TIME
Event attributes
Create one event attribute for
Generating meaningful insights using Process Mining is tied to the quality of the events and attributes captured in the event log. Contextual information about the events and the cases is also critical for the analysis.
This section lists some of the key attributes that you should pay close attention to when capturing data and generating event logs.
Although Appian Process Mining can be used with events that only have start dates, having both start dates and end dates provide a deeper level of granularity to the analysis.
Start dates and end dates allow Appian Process Mining to calculate the duration of the events as well as the lag time between subsequent events.
One of the required attributes for Appian Process Mining, the activity name, is used to group events across cases to create the discovered model and calculate different statistics.
When capturing data in Appian to later create the event log for Process Mining, you must define your events in such a way that their names are clear and precise but not case specific.
Recording this attribute correctly is critical to decrease the complexity of data transformation that may be required to create the event logs.
Below are the recommendations for recording this attribute correctly.
The purchase request 123-abc had been approved by John on 1/1/1970
DON’T
Approved
Purchase Request Approved
DO
Purchase Request Approved By Finance