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.

Description This event log has been artificially generated and curated to provide a comprehensive view of car insurance claims, allowing users to discover and identify bottlenecks, automation opportunities, conformance issues, reworks, and potential fraudulent cases using any process mining software.

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: “First Notification of Loss (FNOL)” -> “Assign Claim” -> “Claim Decision” -> “Set Reserve” -> “Payment Sent” -> “Close Claim”

Attributes: - case ID - activity name - timestamp - claimant name - agent name - adjuster name - claim amount - claimant age - type of policy - car make - car model - car year - date and time of the accident - type of accident - user type

Total number of claims: 30,000

Dates: Claims belong to years 2020, 2021, and 2022.

Disclaimer: Personal names are fake.

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.

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.

Looking for more event logs, use cases and training material?

👉 Join our Skool community

You'll find a hands-on training course and realistic set of 9+ event logs.

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

Modern technologies such as the Internet of Things (IoT) are becoming increasingly important in various domains, including Business Process Management (BPM) research. One main research area in BPM is process mining, which can be used to analyze event logs, e.g., for checking the conformance of running processes. However, there are only a few IoT-based event logs available for research purposes. Some of them are artificially generated and the problem occurs that they do not always completely reflect the actual physical properties of smart environments. In this paper, we present an IoT-enriched XES event log that is generated by a physical smart factory. For this purpose, we create the DataStream/SensorStream XES extension for representing IoT-data in event logs. Finally, we present some preliminary analysis and properties of the log.

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 study analyses an event log, automatically generated by the CeLOE LMS, that records student and lecturer activities in learning. The event log is mined to obtain a process model representing learning behaviours of the lecturers and students during the learning process. The case study in this research is learning in the study program 365 during the first semester of 2020/2021.

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).

This dataset contains details about the events detected by the BigBen internet-wide event monitoring system developed at the University of Wisconsin - Madison. BigBen detects events based on analyzing Network Time Protocol data contributed from NTP server operators. This dataset contains events identified in data provided by 16 NTP servers in 7 US locations, during the period of January 2019 to May 2019. The size of the file is 1GB. It includes a list of /24 IPv4 networks and /96 IPv6 networks in which events were detected.

The method for detecting events is described in the paper:

Meena Syamkumar, Sathiya Mani, Ram Durairajan, Paul Barford and Joel Sommers. "Wrinkles in Time: Detecting Internet-wide Events via NTP", In Proceedings of the IFIP Networking, Zurich, Switzerland, May, 2018.

30

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.

General Description

Our company sells goods overseas. After receiving an order, the shipment of goods is scheduled. According to this schedule, the goods are picked up from the local production site and brought to a terminal where a logistics service provider receives and ships them.

This is an artificial event log according to the OCEL 2.0 Standard simulated using CPN-Tools. Both the CPN and the SQLite can be downloaded.

Process Overview

From a customer order perspective, the process begins when the order is registered at our company (register customer order). After registration, a transport document is created in which details of the further process are recorded (create transport document).

Using this information, the logistics service provider is contacted to coordinate the transport of the ordered goods to the seaport. Twice a week, that provider sends a vehicle to a terminal, with a limited capacity for containers of ordered goods to be transported from the terminal to a seaport. For our company, available capacties vary from vehicle to vehicle, as we are not the only company booking spots. Once the logistics service provider receives our transport documents, they book capacities according to availability and container prioritizations in the upcoming weeks (book vehicles). Once the dates for transporting the goods to the terminal are set, our company contacts a container depot to reserve the required containers (order empty containers).

When a container’s vehicle departure approaches, the goods are prepared, packed and shipped to the terminal. For this purpose, a truck is sent to the container depot (pick up empty container). Meanwhile, the ordered goods to be shipped are packed into handling units at the production site. After loading the handling units (load truck), the truck drives the full container to the terminal (drive to terminal).

At the terminal, the container is picked up by a free forklift and weighed (weigh). Unless the vehicle departure is imminent, the container is placed in the storage location at the terminal (place in stock). Finally, it is moved to the vehicle (bring to loading bay, load to vehicle) which departs at a fixed time (depart).

Despite careful planning, containers sometimes miss a vehicle’s departure. In this case, the container is rescheduled to the next possible vehicle (reschedule container) and kept near the loading ramp until then.

Further information can be found at: https://www.ocel-standard.org/beta/event-logs/simulations/logistics/

General Properties

An overview of log properties is given below.

Property	Value
Event Types	14
Object Types	7
Events	35761
Objects	14013

Control-Flow Behavior

The behavior of the log is described by a respective object-centric Petri net. Also, individual object types exhibit behavior that can be described by simpler Petri nets. See below.

Container	Transport Documents
Customer Order	Truck
Forklift	Vehicle
Handling Unit

Object Relationships

During the process, object-to-object relations can emerge at activity occurrences as follows.

Activity	Source Object Type	Target Object Type	Qualifier
Create Transport Document	Customer Order	Transport Document	TD for CO
Book Vehicle	Transport Document	Vehicle	Regular VH for TD
Book Vehicle	Transport Document	Vehicle	High-Prio VH for TD
Order Empty Containers	Transport Document	Container	CR for TD
Pick Empty Container	Truck	Container	TR loads CR
Load Truck	Container	Handling Unit	CR contains HU
Reschedule Container	Transport Document	Vehicle	Substitute VH for TD

Simulation Model

The CPN used to create this event log can also be downloaded.To obtain simulated data, extract the linked ZIP file and play out the CPN therein, e.g., by using CPN Tools.

The play-out produces CSV files according to the schema of OCEL2.0. This Python notebook can be used to convert these files to an SQLite dump.

For a technical documentation of the simulation model, please open the attached CPN with CPN Tools and see the annotations therein.

Acknowledgements

Funded under the Excellence Strategy of the Federal Government and the Länder. Funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany's Excellence Strategy - EXC-2023 Internet of Production - 390621612. We also thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.

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.

General Description

This process describes the management of customer orders within a company, comprising both the registration and payment of incoming orders, as well as the process of packing and shipping these orders. For these tasks, our company deploys staff in their sales, warehousing, and shipment departments.

This is an artificial event log according to the OCEL 2.0 Standard simulated using CPN-Tools. Both the CPN and the SQLite can be downloaded. The simulation is an extension of the order management log in the former OCEL standard.

Process Overview

At our company, customers place orders (place order) for different products in varying amounts. Each product type has a price and a weight. In the current market situation, there is an inflation that irregularly leads to an increase of prices. These price rises have a negative impact on customers’ purchasing power, i.e., on order volumes.

When a customer places an order, this order is assigned to an employee of our company’s sales department. To foster customer satisfaction, our company has a single-face-to-customer policy. This means that per customer there is one primary sales representative who ought to render all services related to that customer. If that first representative is unavailable, a second sales representative should take care of the order. Should this employee be also unavailable, the order has to be managed by another employee. The tasks of sales employees comprise the registration (confirm order) as well as payment processing (payment reminder, pay order).

In parallel to this, the shipment of goods is prepared. For this, the stock of our company is checked by an employee of the warehousing department for the availability of the ordered items. If necessary, the warehouser reorders the item (item out of stock, reorder item). Items ready for shipment are collected (pick item) for the placement into packages that are addressed to single customers. Here, it may happen that a package content relates to multiple orders, and order volumes are distributed over multiple packages.

After all items allocated to a package have been picked, the package is compiled by a warehousing employee (create package). Later on, this package is picked up by a shipment employee for transport (send package). According to another policy, a warehousing employee should provide assistance to the shipment employee in loading the package. However, oftentimes shippers act contrary to that policy and load packages alone or together with a second shipment employee.

Finally, the package is shipped. Deliveries may fail repeatedly (failed delivery) until successful delivery (package delivered).

The figure below depicts the process in a simplified manner, using an informal process notation to describe the control-flow and the involved object types. A formal description is given along with the artifacts in the next section.

Further information can be found at: https://www.ocel-standard.org/event-logs/simulations/order-management/

General Properties

An overview of log properties is given below.

Property	Value
Event Types	11
Object Types	6
Events	21008
Objects	10840

Control-Flow Behavior

The behavior of the log is described by a respective object-centric Petri net. Also, individual object types exhibit behavior that can be described by simpler Petri nets. See below.

orders	customers
items	employees
packages	products
Full object-centric Petri net

Object Relationships

The company pursues the "one-face-to-the-customer" policy, in which every customer has a dedicated sales representative as well as a deputy (secondary representative). These relationships are described in the log.

Source Object Type	Target Object Type	Qualifier
employees	customers	primarySalesRep
employees	customers	secondarySalesRep

Additionally, object-to-object relations can emerge at executions of specific activities:

Activity	Source Object Type	Target Object Type	Qualifier
create package	package	employee	packed by
send package	package	employee	forwarded by
send package	package	employee	shipped by

Simulation Model

The CPN used to create this event log can also be downloaded.To obtain simulated data, extract the linked ZIP file and play out the CPN therein, e.g., by using CPN Tools.

The play-out produces CSV files according to the schema of OCEL2.0. The provided jupyter notebook can be used to convert these files to an SQLite dump.

For a technical documentation of the simulation model, please open the attached CPN with CPN Tools and see the annotations therein.

Acknowledgements

Funded under the Excellence Strategy of the Federal Government and the Länder. We also thank the Alexander von Humboldt (AvH) Stiftung for supporting our research.

China.

The dataset contains object-centric event logs in the OCEL 2.0 ( https://www.ocel-standard.org/ ) format.

The event logs originate from 100,000 Age of Empires 2 matches. In this real-time strategy game, players control units (like villagers or archers) and build structures (like houses or lumber camps) to create an efficient economy and win against the other players. Players can control multiple units at once, and they can utilize game mechanics to automate parts of the process for them, so they must not trigger every event themselves. The beginning of the game focuses on building economic structures that are as efficient as possible. Normative process descriptions, so-called build orders, describe battle-tested interaction patterns for the beginning of the game, similar to chess openings.

The large object-centric event log contains 1000 matches and has the following properties:

Property	Value
Objects	361,935
Object Types	30
Events	2,372,505
Event Types	829

The following table describes the most important object types:

Object Type or (Group of Object Types)	Explanation
Match	The match represents the competition of two players.
Player	There is one object per player. They are connected to all events that involve player input.
Session	There is one session per player in a match. The session is connected to all events happening on the machine of a player. The events can involve the player directly or they can also be game logic-based events triggered by the game engine.
Villager	Worker units to gather resources and build infrastructure.
Town Center	Central buildings for villager production and resource drop-off. Capable of setting automated gather points to assign tasks for newly created villagers.
(Resource Drop-Off Group)	Includes Lumber Camps, Mining Camps, and Mills. These facilities not only serve as drop-off points but can automatically command workers to gather the corresponding resources upon build completion.
Farms	Agricultural units for a continuous food supply. Farms can sometimes be replenished automatically, depending on game settings or upgrades.
(Military Buildings)	Structures for training military units and producing siege weaponry. Capable of setting gather points to automate unit deployment.
(Research Buildings)	Facilities dedicated to technological advancements and upgrades.
(Military Units)	Units used for combat operations.

The following table describes the most important activities:

Event Type	Explanation
Command Build [Structure]	Issued by players to direct units to construct buildings.
Start Build [Structure]	Marks the beginning of the construction of a building by a designated group of villagers.
Complete Build [Structure]	Signals the completion of a building's construction, making the building operational and freeing up capacity of the constructing units.
Gather [Resource]	Represents the command to a unit to collect resources such as wood, stone, food, or gold.
Command Research [Technology]	Issued by players to initiate a research task in a research building.
Start Research [Technology]	Marks the beginning of the research process once resources arrived.
Complete Research [Technology]	Denotes the completion of a research task, unlocking new technologies or enhancements, and freeing up production capacity.
Command Queue [Unit]	Issued by players to add units to the production queue of a building.
Start Production [Unit]	Marks the beginning of unit production within a facility, as soon as there is capacity.
Complete Queue [Unit]	Signals the end of unit production, resulting in the deployment of a new unit and freeing up production capacity.

The zip file contains filtered object-centric event logs that only contain 10 matches to explore the data set with faster loading time.

This dataset contains synthetic event data of a business process used in the paper "Agent System Mining: Vision, Benefits, and Challenges" for the motivating example.

Abstract: This repository/dataset provides a suite of Python scripts to generate a simulated relational database for inventory management processes and transform this data into object-centric event logs (OCEL) suitable for advanced process mining analysis. The primary goal is to offer a synthetic yet realistic dataset that facilitates research, development, and application of object-centric process mining techniques in the domain of inventory control and supply chain management. The generated event logs capture common inventory operations, track stock level changes, and are enriched with key inventory management parameters (like EOQ, Safety Stock, Reorder Point) and status-based activity labels (e.g., indicating understock or overstock situations).

Overview: Inventory management is a critical business process characterized by the interaction of various entities such as materials, purchase orders, sales orders, plants, suppliers, and customers. Traditional process mining often struggles to capture these complex interactions. Object-Centric Process Mining (OCPM) offers a more suitable paradigm. This project provides the tools to create and explore such data.

The workflow involves:

1. Database Simulation: Generating a SQLite database with tables for materials, sales orders, purchase orders, goods movements, stock levels, etc., populated with simulated data.
2. Initial OCEL Generation: Extracting data from the SQLite database and structuring it as an object-centric event log (in CSV format). This log includes activities like "Create Purchase Order Item", "Goods Receipt", "Create Sales Order Item", "Goods Issue", and tracks running stock levels for materials.
3. OCEL Post-processing and Enrichment:
   • Calculating standard inventory management metrics such as Economic Order Quantity (EOQ), Safety Stock (SS), and Reorder Point (ROP) for each material-plant combination based on the simulated historical data.
   • Merging these metrics into the event log.
   • Enhancing activity labels to include the current stock status (e.g., "Understock", "Overstock", "Normal") relative to calculated SS and Overstock (OS) levels (where OS = SS + EOQ).
   • Generating new, distinct events to explicitly mark the moments when stock statuses change (e.g., "START UNDERSTOCK", "ST CHANGE NORMAL to OVERSTOCK", "END NORMAL").
4. Format Conversion: Converting the CSV-based OCELs into the standard OCEL XML/OCEL2 format using the pm4py library.

Contents:

The repository contains the following Python scripts:

• 01_generate_simulation.py:

  • Creates a SQLite database named inventory_management.db.
  • Defines and populates tables including: Materials, SalesOrderDocuments, SalesOrderItems, PurchaseOrderDocuments, PurchaseOrderItems, PurchaseRequisitions, GoodsReceiptsAndIssues, MaterialStocks, MaterialDocuments, SalesDocumentFlows, and OrderSuggestions.
  • Simulates data for a configurable number of materials, customers, sales, purchases, etc., with randomized dates and quantities.

• 02_database_to_ocel_csv.py:

  • Connects to the inventory_management.db.
  • Executes a SQL query to extract relevant events and their associated objects for inventory processes.
  • Constructs an initial object-centric event log, saved as ocel_inventory_management.csv.
  • Identified object types include: MAT (Material), PLA (Plant), PO_ITEM (Purchase Order Item), SO_ITEM (Sales Order Item), CUSTOMER, SUPPLIER.
  • Calculates "Stock Before" and "Stock After" for each event affecting material stock.
  • Standardizes column names to OCEL conventions (e.g., ocel:activity, ocel:timestamp, ocel:type:).

• 03_ocel_csv_to_ocel.py:

  • Reads ocel_inventory_management.csv.
  • Uses pm4py to convert the CSV event log into the standard OCEL XML format (ocel_inventory_management.xml).

• 04_postprocess_activities.py:

  • Reads data from inventory_management.db to calculate inventory parameters:
    • Annual Demand (Dm)
    • Average Daily Demand (dm)
    • Standard Deviation of Daily Demand (σm)
    • Average Lead Time (lm)
    • Economic Order Quantity (EOQ): (2⋅Dm⋅S)/H (where S is fixed order cost, H is holding cost)
    • Safety Stock (SS): z⋅σm⋅lm (where z is the z-score for the desired service level)
    • Reorder Point (ROP): (dm⋅lm)+SS
  • Merges these calculated parameters with ocel_inventory_management.csv.
  • Computes an Overstock level (OS) as SS+EOQ.
  • Derives a "Current Status" (Understock, Overstock, Normal) for each event based on "Stock After" relative to SS and OS.
  • Appends this status to the ocel:activity label (e.g., "Goods Issue (Understock)").
  • Generates new events for status changes (e.g., "START NORMAL", "ST CHANGE UNDERSTOCK to NORMAL", "END OVERSTOCK") with adjusted timestamps to precisely mark these transitions.
  • Creates a new object type MAT_PLA (Material-Plant combination) for easier status tracking.
  • Saves the enriched and transformed log as post_ocel_inventory_management.csv.

• 05_ocel_csv_to_ocel.py:

  • Reads the post-processed post_ocel_inventory_management.csv.
  • Uses pm4py to convert this enriched CSV event log into the standard OCEL XML format (post_ocel_inventory_management.xml).

Generated Dataset Files (if included, or can be generated using the scripts):

• inventory_management.db: The SQLite database containing the simulated raw data.
• ocel_inventory_management.csv: The initial OCEL in CSV format.
• ocel_inventory_management.xml: The initial OCEL in standard OCEL XML format.
• post_ocel_inventory_management.csv: The post-processed and enriched OCEL in CSV format.
• post_ocel_inventory_management.xml: The post-processed and enriched OCEL in standard OCEL XML format.

How to Use:

1. Ensure you have Python installed along with the following libraries: sqlite3 (standard library), pandas, numpy, pm4py.
2. Run the scripts sequentially in a terminal or command prompt:
   • python 01_generate_simulation.py (generates inventory_management.db)
   • python 02_database_to_ocel_csv.py (generates ocel_inventory_management.csv from the database)
   • python 03_ocel_csv_to_ocel.py (generates ocel_inventory_management.xml)
   • python 04_postprocess_activities.py (generates post_ocel_inventory_management.csv using the database and the initial CSV OCEL)
   • python 05_ocel_csv_to_ocel.py (generates post_ocel_inventory_management.xml)

Potential Applications and Research: This dataset and the accompanying scripts can be used for:

• Applying and evaluating object-centric process mining algorithms on inventory management data.
• Analyzing inventory dynamics, such as the causes and effects of understocking or overstocking.
• Discovering and conformance checking process models that involve multiple interacting objects (materials, orders, plants).
• Investigating the impact of different inventory control parameters (EOQ, SS, ROP) on process execution.
• Developing educational materials for teaching OCPM in a supply chain context.
• Serving as a benchmark for new OCEL-based analysis techniques.

Keywords: Object-Centric Event Log, OCEL, Process Mining, Inventory Management, Supply Chain, Simulation, Synthetic Data, SQLite, Python, pandas, pm4py, Economic Order Quantity (EOQ), Safety Stock (SS), Reorder Point (ROP), Stock Status Analysis.

This event log was used in an exploratory and descriptive study focused on the application of process mining techniques to discover knowledge related to the performance of a customer basic service request process. The dataset enabled the analysis of process behavior, workflow, and process variations based on recorded events.

In addition, this event log can be used by students, researchers, and practitioners interested in learning, practicing, and applying process mining techniques in real-world scenarios, particularly for process discovery, performance analysis, and variant analysis tasks.

The associated study is entitled “Process Mining Applied to a Customer Service Request System: A Data-Based Case Study”, available at ProQuest:https://www.proquest.com/openview/e70e87c918af4fcefcdf912504e6fd67/1?pq-origsite=gscholar&cbl=1006393

The data set contains a set of event logs for evaluating multi-perspective trace clustering approaches in process mining. Event logs were randomly generated from 5 different process models of different complexity levels. The attribute "cluster" refers to the ground truth label. Clusters can only be correctly identified when considering both, the data and the control flow perspective (attributes and trace).