Event log
Learn how to create an event log data source for process analysis in IBM Process Mining. This section contains guidelines for structuring and creating your event log.
The standard approach to process mining involves uploading an event log that contains process execution data. This enables full process mining capabilities including process discovery, conformance checking, and performance analysis. For more information on how to create a single or multi process projects, see Creating a single-process project and Creating a multi-process project.
Event log structure requirements
An event log is a structured data file that records process execution information. To successfully analyze your process, your event log must contain specific fields that describe what happened, when it happened, and who performed the activities.
The following table shows the three mandatory fields every event log must contain:
| Field | Description | Example values |
|---|---|---|
| Process ID (Case ID) | Unique identifier for each process instance. All events belonging to the same process instance must share the same Process ID. | Order-12345, Ticket-98765, Case-00123 |
| Activity | Name of the activity or task performed. This describes what action was taken in the process. | Create Order, Approve Request, Send Invoice, Close Ticket |
| Start time | Timestamp indicating when the activity is started. Must be in a consistent date-time format. | 2024-03-15 09:30:00, 2024-03-15T09:30:00Z |
The following table shows the optional fields an event log can contain. Including these optional fields in your event log enables additional analysis capabilities:
| Field | Description | Enables |
|---|---|---|
| End time | Timestamp when the activity was completed. Allows calculation of activity duration. | Activity duration analysis, service time metrics |
| Resource | Person or system that performed the activity. | Activity map, social network analysis, resource utilization |
| Role | Role or function of the resource performing the activity. | Role-based analysis, organizational insights |
| Working time | Actual time spent working on the activity (excluding waiting time). Tip: While you can map working time directly in the event log, configuring it as an attribute in Data & Settings > Data > Attributes provides more flexibility, including automatic fallback to cost settings when values are missing. For more information, see Attributes and Activity working time.
|
Efficiency analysis, capacity planning |
The following table shows additional custom fields an event log can contain to capture business-specific information:
| Fields | Description |
|---|---|
| Date fields | Additional timestamps (due date, approval date). |
| Numeric fields | Quantities, counts, or measurements. |
| Amount fields | Monetary values or costs. |
| Text fields | Categories, statuses, or descriptions. |
| Integer fields | Whole number values. |
source_id, caseid, activity,
starttime, starttime_s, starttime_ts,
endtime, endtime_s, endtime_ts,
resource, role, workingtime,
automated, PATH, PATHTIME,
BUSINESS_PATHTIME, STDEVENTCOST,
RESOURCEEVENTCOST, CASEVARIANT, CASECOST,
TOTAL_CASES, FILTERED_CASES, INCLUDED_CASES,
IS_RUNNING, IS_CONFORMANT, TOTAL_EVENTS,
FILTERED_EVENTS, user, leadtime_worked,
leadtime, casecost, eventcost,
servicetime_worked, servicetime, waittime_worked,
waittime.To ensure successful process analysis, make sure you adhere to the following guidelines while creating an event log:
- Consistent formatting
- Use the same date-time format throughout the file.
- UTF-8 encoding
- Ensure all file names and content use UTF-8 encoding.
- No missing values
- Required fields must have values for every event.
- Chronological order
- Events should be ordered by timestamp (recommended but not required).
- Standardized activity names
- Use consistent naming for activities to avoid fragmentation.
- Complete cases
- Include all events for each process instance.
- Carriage return
- Ensure the file ends with a carriage return after the last record.
Event log example
The following table shows a properly structured event log:
| ProcessID | Activity | StartTime | EndTime | Resource | Role | Amount |
|---|---|---|---|---|---|---|
| Order-001 | Create Order | 2024-03-15 09:00:00 | 2024-03-15 09:05:00 | John Smith | Sales Rep | 1500.00 |
| Order-001 | Approve Order | 2024-03-15 10:30:00 | 2024-03-15 10:35:00 | Mary Johnson | Manager | 1500.00 |
| Order-001 | Process Payment | 2024-03-15 14:00:00 | 2024-03-15 14:10:00 | System | Automated | 1500.00 |
| Order-001 | Ship Order | 2024-03-16 08:00:00 | 2024-03-16 08:30:00 | Bob Wilson | Warehouse | 1500.00 |
| Order-002 | Create Order | 2024-03-15 09:15:00 | 2024-03-15 09:20:00 | John Smith | Sales Rep | 2300.00 |
| Order-002 | Approve Order | 2024-03-15 11:00:00 | 2024-03-15 11:05:00 | Mary Johnson | Manager | 2300.00 |
In this example:
- Each row represents one activity execution (event).
- Order-001 has four activities in sequence.
- Order-002 has two activities (process still in progress).
- All required fields are present (ProcessID, Activity, StartTime).
- Optional fields provide additional context (EndTime, Resource, Role, Amount).