Subscribe

UiPath Process Mining

The UiPath Process Mining Guide

3. Events

In this transformation step, the events for the entities are defined. Each record in an event table represents one event that took place for the EntityEntity - An object of interest for which you want to see how it behaves through the process.. In most situations, more data records are created. This is the result of joins and unions to link the events to each entity they belong to.

Before building the event tables, it is important to understand the main activities in the process. Prioritize adding activities based on how often they will likely occur and how meaningful they are to the end user. Defining the activities should be an iterative process.
Start with the high-value activities. These are the main activities in the process that describe the core of the process. With only the main activities you can already start validating the process.

Ideal number of activities

An ideal number of activities is between 10 and 20. With a small number of activities there will not be a lot of possible variation in the process. More activities increase the number of process variants. With more process variants, you have to reduce the complexity of the process graphs to understand the flow. This also makes it harder to come to general conclusions.

See the table below.

Number of activities

Result

<10

Low analysis complexity, low number of potential improvements.

10-20

Optimal balance of analysis complexity and potential improvements.

20

High analysis complexity, high number of small improvements.

Define event tables

In an event table, each record should represent exactly one event. On a high level, there are two scenarios on how the data is structured:

  • One or more tables with multiple timestamp columns.
  • One or more tables with one timestamp column (transaction log).

Each scenario requires different transformations.

Multiple timestamp columns

In this scenario, multiple timestamp properties could be defined on the entity table. Consider the example in which an invoice entity is described with three timestamp columns. Each column stores the timestamps of an activity:

  1. creation of the invoice,
  2. deletion of the invoice,
  3. price change.

See the illustration below.

For each of the columns, a new table that represents the events of that activity is created. Each of the event tables needs an activity definition to indicate which event is performed, a timestamp that indicates when this happened, and the invoice ID to know for which invoice the event is performed. See the illustration below for the resulting tables.

The resulting event table for the invoice entity can be created by a union of the separate event tables.
Make sure to only have records in each table for which an activity name is available and a timestamp is known.

Transaction log

This scenario applies when the input data contains a transaction or audit log containing a record for each event that is happening. A transaction log may contain events corresponding to several entities. Consider the example that the transaction log stores events related to purchases and to invoices. See the illustration below.

In this case, you should create an event table per entity. This increases the number of tables in the connector, but it will keep the structure clear. In the example, the log is split into purchase events and invoice events and the columns are renamed. See the illustration below for the resulting tables.

Event tables are usually the largest table in the connector. Make sure to filter out any unwanted records in the joins. A wrong join condition can easily blow up the data volume you have. Look at the number of records in the event table. Is the number higher or lower than expected, then review the join conditions.

Event attributes

The Entity ID, Activity and Event end are mandatory attributes in the event tables. These attributes describe for which entity an event occurs, what the event is, and when the event was performed.

Entity ID

A unique key is required to identify the entity for which a certain event happens. In the scenario of multiple entities in your process, you will also have multiple event tables. The entity ID on each of the event tables is important if you want to create the end-to-end event log. The creation of the event log will be discussed in Chapter 5: Event log.

Activity

The activity describes which event took place. If the name of the activity is not derived from the values in the data, you need to make an expression to define the name yourself. You can infer the activity name from the column names. For example, you can define the activity Create document based on the column document_creation_date. If the column names are less descriptive, you should consult with the process expert for a meaningful name that resonates with the end users.

When naming the activity yourself, best practice is to use the Verb Noun format, such as Create document. Most activities are transactional and this naming convention conveys that. See the table below for some advice on activity naming.

Activity name

Advice

Best practice

Order Order

Avoid ambiguous activity names.

Order material

Ticket

Avoid singular activity names, state what happened to what.

Create ticket

Document cancelled

Avoid passive tense.

Cancel document

Approve credit control check on the sales order

Avoid too long activity names

Approve SO credit check

Event end (timestamp)

The event end attribute indicates when the specific event was performed. For analysis, the event end is used as the timestamp of the event, because usually in the data the time is available of when the event is finished. The event end should be as detailed as possible. A date is generally not sufficient since multiple events can happen on the same date.

Optional attributes

In the event tables you can add additional properties for events. For example, the event detail or supporting properties to define an open or closed case. It is advised to only add the additional attributes after the event logic is validated. Optional attributes may be required for specific visualizations. The attributes Event cost and Event processing time (also called ‘work estimates’) are, for example, required for analyzing automation opportunities.

Updated 3 months ago

3. Events


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.