# Structure of transformations > The following illustration shows the transformation steps of the **Process Mining** app templates. ## Overview The following illustration shows the transformation steps of the **Process Mining** app templates. ![Transformation steps](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-transformation-steps-557007-b6a98f3f-a67399d0.webp) The `models\` folder in the **Transformations** section of **Data transformations** is organized according the structure of the transformation steps. :::note 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. ::: ## 1. Objects In the Objects step, input tables are transformed to object tables. Each object required for the expected events should get its own table. Refer to [Designing an event log](https://docs.uipath.com/process-mining/automation-cloud/latest/user-guide/designing-an-event-log#designing-an-event-log). Additionally, supporting object can also be defined here. In the following example 3 input tables `Invoices_input`, `Invoice_types_input`, and `Customers_input` are joined together to create the object table Invoices. ![Example join](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-example-join-16567-c7b5b95d-685f74b7.webp) ### Guidelines 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. When applicable, the object table relates to another object via an ID field. In the following example, the invoice lines are related to the invoice object via the `Invoice_ID` field. ![invoice lines are related to the invoice object](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-invoice-lines-are-related-to-the-invoice-object-14967-237f826c-741499bc.webp) ### Additional transformations 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. ### Naming convention If the object table names would lead to name clashes later on, add the suffix _base to the tables. ## 2. Events :::note The input for **Event log** and **Custom process** app templates is already a well defined event log for Process Mining. There is no need to transform the data from the source system into the events for Process Mining. ::: In this transformation step, event tables are created for each object. Check out [Designing an event log](https://docs.uipath.com/process-mining/automation-cloud/latest/user-guide/designing-an-event-log#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_created` field in an `Invoices` table. * **Transaction log**: A list of events. Based on how the data is structured, the transformations to create the event tables are different. ### Timestamp fields 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. ![invoices table with three timestamp fields](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-invoices-table-with-three-timestamp-fields-16066-595bbcfd-f2252841.webp) 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 table split into separate events tables](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-invoices-table-split-into-separate-events-tabeles-14529-13cd952c-e2b64fb7.webp) The `Invoices_input table` is split into `Invoice_events_Create_invoice`, `Invoice_events_Delete_invoice`, and `Invoices_events_Change_invoice_price`. The separate event tables can then be merged into a single event table per object, for example `Invoices_events`. ### Transaction log 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). In the following example, the transaction log contains events for the **Purchase Order** and **Invoice** objects. ![Transaction log and event tables](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-transaction-log-and-event-tables-522726-c570d274-f1481d58.webp) 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. | ### Naming convention Name the tables according to the `[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`. ## 3. Business logic 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. In **Process Mining**, there are two additional standard tables defined in this transformation step: `Tags` and `Due dates`. ### Tags 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. Each record in the tags table represents one tag that occurred in the data for a specific case. The mandatory fields for this table are the `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. ![Example Tags table](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-example-tags-table-522664-b0581bc2-b8e402d2.webp) :::note Similar to Events, multiple Tags tables can be present in the data model. ::: #### Naming convention Name the tables according to the structure `[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 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. The mandatory fields for this table are the `Object ID`, `Due date`, `Actual date`, and `Expected date`. ![Example Due dates table](https://dev-assets.cms.uipath.com/assets/images/process-mining/process-mining-example-due-dates-table-522673-119ede90-92fc00c3.webp) :::note Similar to Events, multiple Due dates tables can be present in the data model. ::: #### Naming conventions Name the tables according to the structure `[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`.