- Release notes
- Before you begin
- 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
- Triggering an automation from a process app
- Viewing Process data
- Creating apps
- Loading data
- Customizing process apps
- Publishing Dashboards
- App templates
- Additional resources
Event log input fields
If your data for cases and events is available in one input file, you use the Event log app template.
If you want to create a new Event log or Custom process app, you must upload a dataset that contains the data to be used in the process app.
tsv
(tab-separated) file or .csv
(comma-separated) file that contains a column for each input field.
Event_log_raw
.
Your input data file can have different fields or different field names. However, some fields are mandatory, which means that the data must be available in your input data file for a correct working the process app.
NULL
values.
Below is an overview of the different field types and their default format settings.
Field type |
Format |
---|---|
boolean |
true , false , 1 , 0 |
datetime |
yyyy-mm-dd hh:mm:ss[.ms] , where [.ms] is optional.
Refer to the official Microsoft documentation if you want to change the date format. |
double |
Decimal separator:
. (dot)
Thousand separator: none |
text |
N/A |
integer |
Thousand separator: none |
Below is an overview of the input fields. For each field, the name, the data type, and a short description are displayed. Apart from that, it is indicated whether the field is mandatory.
The Event_log_raw table contains information on the activities executed in the process.
Name |
Data type |
Mandatory Y/N |
Description |
---|---|---|---|
|
text |
Y |
The name of the event. This describes the step in the process. |
|
text |
Y |
The unique identifier of the case the event belongs to. |
|
datetime |
Y |
The timestamp associated with the end of executing the event. |
|
text |
N | A user-friendly name to identify the case. |
|
text |
N | The status of the case in the process. For example, open, closed, pending, approved, etc. |
|
text |
N | The categorization of the cases. |
|
double |
N | A monetary value related to the case. |
Automated *
|
boolean |
N |
Indicates whether the event is manually executed or automated. |
|
double |
N |
The costs for executing the event. |
|
text |
N |
Information related to the event. |
Event_processing_time |
integer |
N | The time for executing the event (in milliseconds). |
|
datetime |
N |
The timestamp associated with the start of executing the event. |
|
text |
N |
The team that executed the event. |
|
text |
N |
The user who executed the event. |
Automated
is part of the input data. However, if you need to derive whether an event is automated or not, you need to customize this
in the data transformations to create that logic based on the required information. It is recommended to do this in the Event_log.sql
file. Locate the statement that contains ...as "Automated"
and replace it, for example, with a statement as displayed below.
case when Event_log_base."User" = 'A' then {{pm_utils.to_boolean('true')}} else {{pm_utils.to_boolean('false')}} end as "Automated"
case when Event_log_base."User" = 'A' then {{pm_utils.to_boolean('true')}} else {{pm_utils.to_boolean('false')}} end as "Automated"