UiPath Process Mining

The UiPath Process Mining Guide

2. Entities


The second table group of a connector is the group of entity tables. This group contains tables that define the entities in the connector.


An entity is an object of interest for which you want to see how it behaves through the process.

Below are some examples to explain entities.

Example 1

In an invoicing process, invoices are entered into the system. Then they are checked. More data may be requested and, finally, invoices are paid.

  • In this example, the invoice is the object of interest for which we can identify interesting steps in the process. Therefore, the invoice is an entity.

Example 2

Before the invoicing process starts, a purchase is made. For this part of the process, a purchase request is entered into the system and the purchase is approved.

  • The purchasing document is also an entity in the process.
  • The purchasing document relates to the invoice. But it is a separate entity on which steps in the process happen independently of the invoice.



Invoices can be of several types, such as employee declarations or customer invoices. The invoice type is a property of the invoice entity, but the invoice type is not an entity by itself.

Define entity tables

From a technical point of view, each entity needs to be stored in a separate table, where each record in a table describes exactly one instance of that entity. To recognize each of the instances individually, there should be a unique identifier available. This Entity ID is later used to define for which entity an event happens.

In the first step of the connector, the input tables are created. These input tables are the base of the entity tables.
Depending on the source system, either one input table or multiple input tables combined define the entity.

Make sure that in the entity tables the Entity ID is always unique. Joining input tables incorrectly may result in duplication. This will give incorrect results in later steps of the transformation, such as duplicate cases and events.

Rename the entities to human-readable names, if needed.

Entity properties

An entity has several properties that describe it and are specific to that entity. An invoice has other properties than, for example, a purchase order. The resulting entity table should contain all the properties that are of interest for analysis. For example, for an invoice these are the Invoice ID (Entity ID), the User ID of the user who entered the invoice in the system, and the Creation date of the invoice.
See the illustration below for an example entity table for an invoice.


Additional information about entity properties can be stored in different tables. For example, information related to the user is stored in a separate user table. If you want to have the name of the user instead of the User ID, you should take this information from the user table.

A user table is an example of Master data.

See the illustration below for an example of a master table that stores additional data on users.


The user information can be made available on the entity table by joining the user table with a left join to the entity table. A left join makes sure that the entity table is enriched with the master data when available, but does not remove records from the entity table itself. Make sure that after this join, the entity ID remains unique on the entity table and no data duplication is caused.

Create separate tables for master data based on the input tables. This helps to easier understand and maintain the connector. It allows you to abstract from the original table name in the source system to a more generic name, while keeping the original name for traceability as well.

Multiple entities

The number of entities that are of interest in a process can vary depending on the complexity of the process.

Simple processes

In a relatively simple process, only one entity may be involved. For example, in an invoicing process in which you are only interested in events that take place related to the invoice.

Complex processes

In more complex processes, multiple entities can be of interest. An example is a Purchase-to-Pay process in which the process from requesting a product up to the invoice being paid covers steps related to multiple entities. In a process with multiple entities, always make sure that the relation between these entities is present in the entity tables. For example, if an invoice is created for a certain purchasing document, the purchasing document identifier should be a property on the invoice entity table.

Updated 5 months ago

2. Entities

Suggested Edits are limited on API Reference Pages

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