I utilized a publicly accessible dataset (creators: Claudio Amaral, Marcelo Fantinato and Sarajane Peres), with slight modifications, for my academic work. This is an event log of an incident management process extracted from data gathered from the audit system of an instance of the ServiceNowTM platform used by an IT company. The event log is enriched with data loaded from a relational database underlying a corresponding process-aware information system. Information was anonymized for privacy.

This datasets includes 9 event logs, which can be used to experiment with log completeness-oriented event log sampling methods.

· exercise.xes: The dataset is a simulation log generated by the paper review process model, and each trace clearly describes the process of reviewing papers in detail.

· training_log_1/3/8.xes: These 3 datasets are human-trained simulation logs for the 2016 Process Discovery Competition (PDC 2016). Each trace consists of two values, the name of the process model activity referenced by the event and the identifier of the case to which the event belongs.

· Production.xes: This dataset includes process data from production processes, and each track includes data for cases, activities, resources, timestamps, and more data fields.

· BPIC_2012_A/O/W.xes: These 3 dataset are derived from the personal loan application process of a financial institution in the Netherlands. The process represented in the event log is the application process of a personal loan or overdraft in a global financing organization. Each trace describes the process of applying for a personal loan for different customers.

· CrossHospital.xes: The dataset includes the treatment process data of emergency patients in the hospital, and each track represents the treatment process of an emergency patient in the hospital.

This repository contains the ProMiSE event log, a multi-perspective event log capturing how process mining analysts interact with tools, visualizations, and analysis artifacts during process mining analysis sessions.

The event logs in this resource are derived from video-recorded analysis sessions with process mining analysts.
Each trace represents one analyst session and describes the analyst’s behavior over time from a particular perspective:

1. Tool Function (How) — which tool function the analyst used, described in a tool-agnostic manner.
2. Analysis Focus (What) — what aspect of the process, data, or artifact the analyst focused on.
3. Visualizations — which type of visualization the analyst used during the analysis.

The event log is intended to support research on analyst behavior, e.g., through the understanding of user interaction patterns, as well as the development/testing of methods and techniques that work on multi-perspective and multi-granular event logs.

Repository Contents

The repository contains the following files:

Dataset Overview

The complete ProMiSE event log consists of:

• 40 traces, where each trace corresponds to one analyst session.
• 5724 events in total.
• 26.6 hours of video-recorded process mining analysis sessions.
• Three perspectives: Tool Function, Analysis Focus, and Visualizations, recorded in field Type.
• Up to four levels of event-name granularity, represented by fields L1, L2, L3, and L4.

The perspective-specific event logs contain:

Data Collection

The data was collected in 2021 during video-recorded analysis sessions with process mining analysts from industry and academia.

Participants were asked to analyze the Road Traffic Fine Management event log and investigate why traffic fines were not paid and, where possible, identify root causes of non-payment. Analysts were allowed to use and combine different process mining tools, including bupaR, Celonis, Disco, PM4Py, and ProM.

The video recordings were segmented into event logs using a qualitative coding approach. Each coded segment was transformed into one or more events with a start time, end time, and event name. Think-aloud protocols were used to support the interpretation of the analysts’ behavior, which was essential to disambiguate the Analysis Focus.

Event Log Structure

The complete event log contains the following main fields:

Not all columns are present in all perspective-specific files. For example, UsedTool is only relevant for Tool Function events.

Multi-Perspective Nature of the Log

The complete event log combines three perspectives on the same analysis process. These perspectives may overlap in time, but they do not always have identical segmentations.

For example, a single time segment may correspond to:

• one Tool Function event,
• one Analysis Focus event,
• and one Visualization event.

In other cases, only one or two perspectives may be coded for a given segment. As a result, the complete event log contains partially ordered behavior and should not always be treated as a strictly sequential log.

Users who require totally ordered event sequences may prefer to work with the perspective-specific files, depending on their analysis goal.

Multi-Granular Event Names

The event names preserve multiple abstraction levels. These levels are available both as part of the full Event_name and as separate columns:

• L1
• L2
• L3
• L4

This allows researchers to choose the granularity level most suitable for their analysis. For example, one analysis may use coarse-grained L1 activities, while another may use more detailed L2 or L3 event names.

The file EventNames.pdf provides an overview and description of the coding system.

Possible Uses and Innovation for the BPM Community

This resource can be used to conduct or validate empirical research on the process of process mining, e.g., to explore how process mining analysts interact with tools and artifacts; or how visualizations support focusing on specific aspects.

In addition, the multi-perspective and multi-granular character of the log makes it an interesting resource to develop and validate:

• methods for handling unstructured or highly variable event logs derived from (human) ueser behavior;
• techniques for mining multi-perspective event data, where several events describing the same phenomenon from different angles may overlap in time;
• approaches for working with multi-granular event data, where the granularity of activity names can be chosen and adjusted during the analysis.

Related Publications

This resource has been used to analyze the behavior of process mining analysts in two case studies.

• Zerbato, F., Zimmermann, L., Vrotsou, K., & Weber, B. (2025). From analysis to findings: How do process mining analysts discover results?. Information Systems, 102596.
• Zimmermann, L., Zerbato, F., & Weber, B. (2026). Visualization Use in Process Mining Analysis. In International Conference on Business Process Modeling, Development and Support, International Conference on Evaluation and Modeling Methods for Systems Analysis and Development (pp. 55-72). Springer, Cham.

In addition, the following paper describes the extraction of the event sequences from the video-recordings in more detail, presenting it as a method to study the use of visualizations by process analysts across different tools.

• Zimmermann, L., Zerbato, F., Vrotsou, K., & Weber, B. (2025, June). A Process‐Oriented Approach to Analyze Analysts' Use of Visualizations: Revealing Insights into the What, When, and How. In Computer Graphics Forum (Vol. 44, No. 3, p. e70104).

License

CC BY 4.0

In this work, we extract an event log from the MIMIC-IV-ED dataset by adopting a well-established event log generation methodology, and we name this event log MIMICEL. The data tables in the MIMIC-IV-ED dataset relate to each other based on the existing relational database schema, and each table records the individual activities of patients along their journey in the emergency department (ED). While the data tables in the MIMIC-IV-ED dataset catch snapshots of a patient journey in the ED, the extracted event log MIMICEL aims to capture an end-to-end process of the patient journey. This will enable us to analyse the existing patient flows, thereby improving the efficiency of an ED process.

This dataset contains event logs on the Container Dwell Time process at the Container Terminal. The Dwelling Time process is the process and time calculated from the time the container is unloaded and lifted from the ship until the container leaves the port terminal through the main door.

Source: - https://www.sciencedirect.com/science/article/pii/S2352340924008692 - https://data.mendeley.com/datasets/yvp2b4rtp3/1

This dataset contains a real-life event log pertaining to a loan application process of a Dutch financial institute. It includes all applications filed through an online system in 2016 and their subsequent events until February 1st, 2017.

Data Scale & Structure

• Total Events: 1,202,267
• Total Cases (Traces): 31,509
• Average Events per Case: ~38
• Process Type: Implicitly structured workflow with multiple offers per application.

Citation & Attribution

Original Author: B.F. van Dongen, Eindhoven University of Technology. Link: https://data.4tu.nl/articles/dataset/BPI_Challenge_2017/12696884 License: CC BY 4.0 (Attribution).

XES software event log obtained through instrumenting JUnit 4.12 using the tool available at {https://svn.win.tue.nl/repos/prom/XPort/}. This event log contains method-call level events describing a single run of the JUnit 4.12 software, available at {https://mvnrepository.com/artifact/junit/junit/4.12} , using the input from {https://github.com/junit-team/junit4/wiki/Getting-started}. Note that the life-cycle information in this log corresponds to method call (start) and return (complete), and captures a method-call hierarchy.

This realistic incident management event log simulates a common IT service process and includes key inefficiencies found in real-world operations. You'll uncover SLA violations, multiple reassignments, bottlenecks, and conformance issues—making it an ideal dataset for hands-on process mining, root cause analysis, and performance optimization exercises.

Want more realistic event logs like this one and a descriptive use case handbooks?

This dataset is one of 9 realistic event logs built from real-world business processes. The full collection covers Accounts Payable, Logistics, Order-to-Cash, Incident Management, Mortgage Applications and more.

At www.processminingdata.com you can download a free sample event log and use case handbook — including KPIs to track, root causes to investigate, and how to quantify the business impact of each process.

👉 Get your free sample at www.processminingdata.com

Standard Process Flow: Ticket Created -> Ticket Assigned to Level 1 Support -> WIP - Level 1 Support -> Level 1 Escalates to Level 2 Support -> WIP - Level 2 Support -> Ticket Solved by Level 2 Support -> Customer Feedback Received -> Ticket Closed

Total Number of Incident Tickets: 31,000+

Process Variants: 13

Number of Events: 242,000+

Year: 2023

File Format: CSV

File Size: 65MB

The synthetic event logs in this dataset were automatically generated using CPN Tools in the XES format. The generated event logs result from executing the provided process model through the simulation feature in CPT Tools.

The Petri net model (ecom_web_application.cpn) we used was designed based on the specification of a popular open-source e-commerce shopping website named OsCommerce (version 2.3.4.1). The following aspects were prioritized when developing the model: • Including all the three supported roles by OsCommerce (admin, guest, and registered users). • Enforcing business rules through guard inscription associated with transitions. • Allowing a more realistic behavior through weighted random selection. • Maintaining users’ state during the simulation.

Simulating the execution of the OsCommerce-based process model yielded an XES event log of 910 cases. Around 10,500 events from 56 classes were distributed among the cases. The events count per case ranged from 0 to 105 with a mean value of 11, and the average number of event classes per case was around 6.

The generated event log reflected realistic behaviors for all the supported roles by assigning weights to the simulator transition decisions: 10% of customers placed an order, admin traffic represented 15% of the overall, customers did not usually enter long loops (e.g., add/remove from cart, login/logout), and customers followed links within the website as intended.

IoT devices generate constant streams of data, reporting their health and performance in real-time. Device interactions are logged, capturing information such as connection statuses, data transmission effectiveness, and error events. This operational log portrays the intricate dynamics of a connected environment, where high-traffic devices create clusters of log entries and sporadic anomalies suggest communication errors or unusual behaviors. Each entry represents a snapshot of a device's status, allowing for in-depth analysis of performance trends over time.

The dataset consists of a single table, iot_events, where each row details an individual IoT event, including timestamps, device identifiers, event types, and any error codes that may have occurred. Analyzing these logs helps developers understand how devices communicate, identify patterns of normal operation, and detect deviations that could signify potential issues. By correlating event types with timestamps, trends in device performance can be established, and the effectiveness of data pipelines can be evaluated.

With this dataset, users can explore various questions such as: How often do devices report errors? Which devices are most reliable in terms of data transmission? Are there particular times of day when anomalies are more likely to occur? This synthetic data provides an excellent opportunity to practice data analysis skills, work on anomaly detection algorithms, and refine skills in managing and interpreting large volumes of log data.

Overview

This is the WFIP2 event log covering all sites and instruments for the entire project duration.

Final Event Log and Common Case Study Set

Additional details may be added here.

Description:

This dataset provides an object-centric event log (OCEL) representation of the publicly available Enron email corpus. The OCEL format allows for a richer analysis of interconnected processes and objects, making it particularly suitable for advanced process mining techniques, communication pattern analysis, and social network exploration.

The event logs were generated from a pre-processed CSV version of the Enron emails using a custom Python script leveraging the PM4Py library. The script parses individual emails to extract key information, including:

• Timestamps: Derived from the 'Date' field of emails, parsed into timezone-aware datetime objects.
• Activities: Inferred from email subject prefixes (e.g., "Re:" becomes "Response", "Fw:" becomes "Forwarding", "Invitation:" becomes "Invitation"). Emails without recognized prefixes are assigned a "Default" activity.
• Objects: Two primary object types are identified:
  • EMAILADDRESS: Extracted from 'From', 'To', and 'Cc' fields.
  • MESSAGEID: Extracted from 'Message-ID', 'In-Reply-To', and 'References' fields, prefixed with "MID_" in the OCEL to ensure unique object identifiers across types.
• Attributes: Event attributes include the original cleaned subject and content of the email.
• Relationships: Events (emails) are linked to EMAILADDRESS objects with qualifiers 'FROM', 'TO', or 'CC'. Events are linked to MESSAGEID objects with qualifiers 'MESSAGEID' (for the email's own ID), 'INREPLYTO', or 'REFERENCES' to trace conversational threads.

To accommodate various analytical needs and computational resources, the dataset is provided in three distinct checkpoints:

1. Top 10,000 Emails: An OCEL generated from the first 10,000 emails processed.
2. Top 100,000 Emails: An OCEL generated from the first 100,000 emails processed.
3. All Emails: An OCEL generated from all emails processed by the script from the input emails.csv file.

This dataset can be valuable for researchers and practitioners seeking to apply object-centric process discovery, conformance checking, and enhancement techniques to a large, real-world communication log.

Keywords: Object-Centric Event Log, OCEL, Process Mining, Enron Dataset, Email Analysis, Communication Networks, Social Network Analysis, PM4Py

Dataset

This dataset was created by boomerang476

Contents

China.

Dataset

This dataset was created by Mehul Katara

Contents

This dataset contains event logs on the Container Dwell Time process at the Container Terminal. The Dwelling Time process is the process and time calculated from the time the container is unloaded and lifted from the ship until the container leaves the port terminal through the main door.

Franchises strategize and compete, managing teams to excel through seasons in a highly dynamic sports simulation. Coaches and managers analyze player performance, adjusting training regimens and tactics based on in-game events and statistics. Each match creates a wealth of data, detailing player contributions, game outcomes, and critical incidents such as injuries or standout performances that can influence the future of the organization. While many matches maintain predictable patterns in scoring and player deployment, the unpredictable nature of sports often leads to significant shifts in team performance metrics.

The dataset comprises several interconnected tables that together provide a comprehensive view of franchise operations. The 'matches' table records the outcomes and key events of each game, linking to 'teams' which outlines the franchises competing. Each 'team' comprises multiple 'players' whose specific performance metrics are tracked in their respective table, including goals scored, assists, and disciplinary actions. 'Managers' are associated with each team, allowing for analysis of decision-making and its impact on match outcomes. Additionally, the 'youth_academy' table captures the development of potential future stars, detailing player progression and training outcomes that could affect the overall team composition in subsequent seasons.

This data is especially valuable for those looking to explore relationships between player performance and team success, evaluate training effectiveness, or analyze the impact of managerial decisions on match outcomes. Practitioners can simulate various scenarios, such as player injuries or strategic adjustments, to assess how these factors alter team performance over time. As a synthetic dataset, it provides a safe environment for developers and analysts to hone their skills in data analysis and interpretation without the complications of real-world data.

Description:

This dataset provides an object-centric event log (OCEL) representation of the publicly available Enron email corpus. The OCEL format allows for a richer analysis of interconnected processes and objects, making it particularly suitable for advanced process mining techniques, communication pattern analysis, and social network exploration.

The event logs were generated from a pre-processed CSV version of the Enron emails using a custom Python script leveraging the PM4Py library. The script parses individual emails to extract key information, including:

• Timestamps: Derived from the 'Date' field of emails, parsed into timezone-aware datetime objects.
• Activities: Inferred from email subject prefixes (e.g., "Re:" becomes "Response", "Fw:" becomes "Forwarding", "Invitation:" becomes "Invitation"). Emails without recognized prefixes are assigned a "Default" activity.
• Objects: Two primary object types are identified:
  • EMAILADDRESS: Extracted from 'From', 'To', and 'Cc' fields.
  • MESSAGEID: Extracted from 'Message-ID', 'In-Reply-To', and 'References' fields, prefixed with "MID_" in the OCEL to ensure unique object identifiers across types.
• Attributes: Event attributes include the original cleaned subject and content of the email.
• Relationships: Events (emails) are linked to EMAILADDRESS objects with qualifiers 'FROM', 'TO', or 'CC'. Events are linked to MESSAGEID objects with qualifiers 'MESSAGEID' (for the email's own ID), 'INREPLYTO', or 'REFERENCES' to trace conversational threads.

To accommodate various analytical needs and computational resources, the dataset is provided in three distinct checkpoints:

1. Top 10,000 Emails: An OCEL generated from the first 10,000 emails processed.
2. Top 100,000 Emails: An OCEL generated from the first 100,000 emails processed.
3. All Emails: An OCEL generated from all emails processed by the script from the input emails.csv file.

Each checkpoint is available in the .jsonocel format (OCEL 2.0 standard), ready for use with PM4Py and other OCEL-compatible process mining tools. This dataset can be valuable for researchers and practitioners seeking to apply object-centric process discovery, conformance checking, and enhancement techniques to a large, real-world communication log.

Keywords: Object-Centric Event Log, OCEL, Process Mining, Enron Dataset, Email Analysis, Communication Networks, Social Network Analysis, PM4Py

An example of ER visit event logs.

Patients embark on clinical trials to explore new medication options, providing critical data on safety and efficacy. Throughout their journey, each patient interacts with a structured framework that records their enrollment in trials, the consent forms they approve, the medications they receive, and any adverse events that occur during the process. This rigorous tracking helps ensure that every phase of the trial is documented, facilitating a thorough analysis of the treatment's impact.

The tables in this dataset interconnect in meaningful ways. Each patient is represented in the patients table, detailing their unique identifiers and demographic information. They participate in trials found in the trials table, where each row corresponds to a different study, describing the trial’s objectives and phases. Consent forms, outlined in their specific table, capture the approval process that patients undergo before participating, highlighting variations in the consent process across different trials. The medications table logs the various drugs administered to patients during their participation, while the adverse_events table records any negative reactions or side effects experienced, which are essential for assessing medication safety.

This dataset provides valuable insights into clinical trial operations, allowing practitioners to investigate questions such as: How do different consent forms impact patient safety and trial outcomes? What patterns emerge in adverse events related to specific medications? How does patient demographic information correlate with trial enrollment and response to treatment? Practicing with this data can enhance skills in data analysis, visualization, and interpretation within a healthcare context.

It's important to note that the data here is synthetic, designed to simulate real-world clinical trial environments while protecting individual privacy.