- Release notes
- Before you begin
- Managing access
- Getting started
- Integrations
- Working with process apps
- Working with dashboards and charts
- Working with process graphs
- Working with Discover process models and Import BPMN models
- Showing or hiding the menu
- Context information
- Export
- Filters
- Sending automation ideas to UiPath® Automation Hub
- Tags
- Due dates
- Compare
- Conformance checking
- Root cause analysis
- Simulating automation potential
- Starting a Task Mining project from Process Mining
- Triggering an automation from a process app
- Viewing Process data
- Creating apps
- Loading data
- Transforming data
- Customizing process apps
- Publishing process apps
- App templates
- Notifications
- Additional resources
Process Mining
Structure of transformations
models\ folder in the Transformations section of Data transformations is organized according the structure of the transformation steps.
The Event log and Custom process app templates have a simplified data transformations structure. Process apps created with these app templates do not have this folder structure.
In the Object step, input tables are transformed to objec tables. Each object required for the expected events should get its own table. Refer to Designing an event log. Additionally, supporting object can also be defined here.
Invoices_input, Invoice_types_input, and Customers_input are joined together to create the object table Invoices.
Follow these guideline when creating an objects table.
- There is one object ID field, which is unique for each data record.
- All object fields that are needed for data analysis are present.
- All object fields have names that are easy to understand.
Invoice_ID field.
Not all input tables are transformed into object tables. Also, other input tables may contain relevant information, such as the Customers table in the example. It may be convenient to define them in the Objects step as separate tables such that they can be reused in the data transformations.
In this transformation step, event tables are created for each object. Check out Designing an event log. Each record in an event table represents one event that took place. There are two scenarios on how the data is structured:
- Timestamp fields: Fields on an object table with a timestamp for an event. For example, the
Invoice_createdfield in anInvoicestable. - Transaction log: A list of events.
Based on how the data is structured, the transformations to create the event tables are different.
In this scenario, the values of a timestamp field must be transformed into separate records in an event table. The following example is an invoices table that contains three timestamp fields.
Each timestamp field is used to create a separate event table. For every record that the timestamp field contains a value, create a table with the Invoice ID, the name of the event (Activity), and the timestamp the event took place (Event end).
Invoices_input table is split into Invoice_events_Create_invoice, Invoice_events_Delete_invoice, and Invoices_events_Change_invoice_price.
Invoices_events.
If events are stored in a transaction log, the relevant events per object should be identified. Create a table per object and store corresponding object ID, the name of the event (Activity), and the timestamp the event took place (Event end).
The following fields are mandatory in an event table. All records in the event tables should contain a value for these fields.
|
Field |
Description |
|---|---|
|
Object ID |
ID of the object for which the event happens. For example, the Invoice ID. |
|
Activity |
The activity describes which action took place on the object. |
|
Event end |
The event end field indicates when the specific event was finished. Ideally, this should be a datetime field, rather than a date. |
[Activity] + _events to create one event file per activity, or [Object] + _events to create one event file per object. For example Purchase_order_created_events, Purchase_order_approved_events, or one file with all purchase order activities combined Purchase_order_events.
In the last transformation step, business logic is added as needed for data analysis. Additional derived fields can be added to existing tables here. For example, specific throughput times or Boolean fields that are used in KPIs in dashboards.
Tags and Due dates.
Tags are properties of objects, which signify certain business rules. Tags are typically added to make it easy to analyze these business rules. For example:
- Invoice paid and approved by the same person.
- Invoice approval took more than 10 days.
- Check invoice activity skipped.
Object ID and the Tag. Not all objects will have a tag and some objects may have multiple tags. The following illustration shows an example Tags
table.
Similar to Events, multiple Tags tables can be present in the data model.
Naming convention
[Tag] + _tags to create one file per tag, or [Object] + _tags to create one file per object. For example Invoice_approved_and_paid_by_same_person_tags, Invoice_approval_too_late_tags, or one file with all invoice tags combined Invoice_tags.
Due dates represent deadlines in the process. These are added to the data to analyze whether activities are performed on time for these due dates or not.
Each record in the due dates table represents one due date for a certain object. Example due dates are:
- a payment deadline for a payment.
- an approval deadline for an purchase order.
Object ID, Due date, Actual date, and Expected date.
Similar to Events, multiple Due dates tables can be present in the data model.
Naming conventions
[Due date] + _due_dates to create one file per due date, or [Object] + _due_dates to create one file per object. For example Payment_deadline_due_dates, Payment_deadline_with_discount_due_dates, or one file with all invoice due dates combined Payment_due_dates.
