TL;DR: An event log is the fuel of process mining: a table of what happened, for which case, and when. Algorithms use that structure to reconstruct real process flows from system data.
What you will learn
- The three mandatory fields every event log needs
- How cases, activities, and timestamps work together
- Optional attributes that unlock richer analysis
- Everyday data-quality traps and how to spot them
- A practical checklist before you call a log mining-ready
What is an event log?
In process mining, an event log is a collection of events: atomic records that something occurred in the execution of a process. Each event is tied to a case (one instance of the process), labeled with an activity (what kind of step it was), and ordered in time via a timestamp.
Definition: An event log is process data arranged so that each event answers which case, which activity, and when. Those three answers form the minimal input for discovery, conformance, and enhancement.
You can picture a spreadsheet:
| case_id | activity | timestamp | resource | amount |
|---|---|---|---|---|
| PO-1001 | Create PO | 2026-03-01 09:12 | alice | 1200 |
| PO-1001 | Approve | 2026-03-01 14:02 | bob | 1200 |
| PO-1002 | Create PO | 2026-03-01 10:44 | alice | 500 |
| PO-1001 | Receive goods | 2026-03-05 11:20 | warehouse | 1200 |
Sort by case and time, and you have the story of each purchase order. Multiply by tens of thousands of cases, and you have an event log worth mining.
Why do the three core fields matter?
1. Case identifier
The case ID stitches events into a single journey. Without it, you only have a pile of clicks. Choosing the case is a design decision: order number versus shipment versus invoice can yield different processes. Wrong case grain is one of the most common reasons maps become unreadable.
2. Activity name
Activities are the vocabulary of your process map. "Approve," "Approval_Completed," and "APPR_OK" may be the same step, or three different ones. Inconsistent naming creates false variants. Agree on a business-friendly glossary early.
3. Timestamp
Timestamps order events and enable waiting-time analysis. Prefer event occurrence time over load time. Watch for timezone mixes, midnight batch stamps, and clocks that only record dates (not times). All of these distort performance views.
Optional attributes that earn their keep
Once the core three are solid, attributes turn maps into management tools:
| Attribute type | Examples | Helps you… |
|---|---|---|
| Resource / org | user, team, role | Spot handoff delays and workload skew |
| Data / business | amount, region, channel | Explain path choices and outliers |
| Lifecycle | start vs. complete | Separate processing time from wait time |
| Outcome | approved, churned, SLA_met | Tie paths to results |
| System | ERP, CRM, ticket tool | Debug integration gaps |
You do not need every column on day one. Add attributes when they answer a written question (for example, "Does rush channel skip credit check?").
How event logs relate to real systems
Rarely does a perfect log fall out of one table. Typical construction steps:
- Identify the case. Pick the business object that defines one unit of work.
- Find candidate events. Status changes, completed tasks, posted documents, API callbacks.
- Normalize activities. Map technical codes to human labels; drop noise events.
- Align time. Convert timezones; decide how to handle missing times.
- Join carefully. When events span systems, verify the join key truly means the same case.
- Validate with samples. Walk 10 to 20 known cases with a domain expert before scaling.
Formats such as XES exist for interchange. CSV or Parquet with clear columns is often enough for learning and pilots. The conceptual model matters more than the file extension.
What does good enough data quality look like?
Perfection is rare. Aim for decision-grade quality:
- Completeness for the scoped process. Critical steps appear for most cases you care about.
- Consistent case IDs. The same real-world case does not fracture into multiple IDs unnoticed.
- Stable activity vocabulary. Synonyms merged; meaningless technical chatter filtered.
- Plausible timestamps. Events rarely go backward; durations make business sense.
- Enough volume. Small samples hide rare but costly paths.
Red flags to investigate immediately
- Huge share of cases with only one event (broken extraction or wrong case grain)
- Activities that appear after "closed" status (lifecycle confusion)
- Identical timestamps for long chains (batch posting)
- Duplicate events from retries or double logging
- Sudden vocabulary changes after a system upgrade (version the glossary)
Event logs vs. related data concepts
| Concept | Relationship to event logs |
|---|---|
| Transactional tables | Source raw material; need shaping into events |
| Audit / change logs | Often useful, but noisy and incomplete as-is |
| BI fact tables | May aggregate away the sequence mining needs |
| Clickstreams | Can be event logs if a case notion exists |
| Object-centric data | Multiple object types; advanced relative to classic single-case logs |
Classic process mining assumes one primary case notion per log. More advanced object-centric approaches relax that. Learn the single-case event log first; it covers most 101 use cases.
A plain-English story: from ticket tool to log
Support tickets already feel like cases. Each ticket ID is a case. Status transitions and worklog categories become activities. Created and updated times become timestamps. Agents become resources. Priority and product line become attributes. After cleaning duplicate "updated" noise, you can discover reassignment loops and enhance with time-to-first-response by priority, without inventing a new system of record.
Key takeaways
- Event logs need case ID, activity, and timestamp as the non-negotiable core.
- Case grain and activity naming are design choices that shape every downstream map.
- Optional attributes power enhancement; add them to answer specific questions.
- Building a log is mostly data engineering and business glossary work, not magic.
- Validate with known cases before you trust discovery or conformance results.
FAQ
What is an event log in process mining?
An event log is a structured record of what happened in a process: each row (event) usually names a case, an activity, and a timestamp. Mining algorithms use these events to reconstruct paths, timing, and deviations across many cases. Think of it as the story of every case, not a monthly KPI rollup.
What are the minimum fields in an event log?
You need three fields: case identifier, activity (or event) name, and timestamp. Everything else (resource, cost, status, system) is optional enrichment. Missing any of the three core fields breaks process reconstruction and turns mining into ordinary analytics.
Is an event log the same as a system audit trail?
Related but not identical. Audit trails can feed an event log, but mining needs a consistent case notion and activity vocabulary. Raw audit dumps often require filtering, joining, and renaming before they become a usable log that stakeholders recognize.
What makes event log data quality good enough?
Reliable case IDs across steps, meaningful activity names, trustworthy timestamps, and enough completed cases. Completeness and consistency matter more than perfect coverage of every edge-case interaction on day one. Iterate the log as questions deepen.
Further reading
- Process Mining Handbook (open access): https://doi.org/10.1007/978-3-031-08848-3
- Previous: The Three Questions: Discover, Check, Enhance
- Next: Reading a Process Map Without Drowning
- Related: Process Mining 101: What It Is (and Is Not)
Attribution
Educational synthesis inspired by the open-access Process Mining Handbook (van der Aalst and Carmona, eds., 2022), https://doi.org/10.1007/978-3-031-08848-3. This article is not a substitute for the handbook. It is not legal, audit, or vendor advice.