UiPath Process Mining

The UiPath Process Mining Guide

Connector Development Guide


This document aims to guide you through the different steps of developing a Connector for UiPath Process Mining.


Before getting started with this guide, make sure your chosen process and data source are suitable for a Process Mining implementation. Process Mining requires:

  • an activity to define the performed process events;
  • a timestamp to show when each step happened,
  • an identifier to tie all events in one process execution.



Without one of these three mandatory elements, a Process Mining analysis is not possible. Therefore, it is important to know the tables and fields of your data before getting started.

Data model

Many of these steps are part of the data transformation process. This transformation is necessary since Process Mining requires the data in the form of an event log to be able to visualize it. This format is called the data model. The data model describes the tables and fields that need to be part of the output dataset generated by the connector. However, most source systems do not provide data in this format. Therefore, it is necessary to transform the data.


To help with the data transformation, Process Mining has created several connectors which can be used as a template for loading, cleaning, and transforming data. These pre-built connectors are specific for a certain system and process such as the SAP Connector for Purchase-to-Pay Discovery Accelerator.

When starting with a new project, it is recommended to check whether you can make use of UiPath pre-built connectors. In the simplest cases, the input data fits directly with one of the connectors, and there is no need for a custom connector. If neither of these options are applicable, you will need to build a connector yourself.

Building a connector

The goal of a connector is to produce a dataset that fits the data model. The most standard Process Mining data model consists of a Cases and an Event log table. Alternative data models consist of several Entity and Events tables. Independent of the data model, we recommend structuring the first transformation steps of the connector as listed below.




1. Input

Define the raw data from the source system in the connector.

2. Entities

Define the entities relevant to the process.

3. Events

Define the events that happen for the entities.

If Event log, Tags, or Due dates are part of the data model, the following two transformation steps must be performed.



4. Event logs

Combine events for different entities in event logs.

5. Business logic

Enrich the data with standardized concepts. This also includes Tags and Due dates.

Supporting models

In SQL, not all transformations can be computed in the same table. The reason for this may be aggregates or properties that cannot be expressed in a single select statement. You can create supporting tables for this purpose. Creating a supporting table in the database allows you to use the model in multiple transformations. If it is not needed to reuse the model, the supporting transformation can also be added as a preprocessing query in the existing table. It is a balance between creating supporting tables and preprocessing queries to get readable transformations.

To make a distinction between supporting transformations and the other transformations, you can group them in a separate sub directory. The default name of this group should be supporting_models, but more descriptive names are also allowed.

Naming conventions

Completing the above steps must result in a main folder structure for the connector with the following naming conventions:

  • 1_input
  • 2_entities
  • 3_events
  • 4_event_logs
  • 5_business_logic

In any of these main folders, the folder supporting_models may be present, or any other grouping that enhances the understandability of the transformations.
It is required that models only depend on models until the same main group. It is therefore not allowed to define tables in 3. Events which are dependent on a table from 4. Event_logs.

About this guide

This guide leads you through the steps to create these different sections and provides you with conceptual explanations as well as tips and tricks for the actual implementation. The guide is written in a generic way so that you can apply it to any kind of process and system. To successfully follow this guide, make sure you are familiar with your input data and its underlying model.

Updated 5 months ago

Connector Development Guide

Suggested Edits are limited on API Reference Pages

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