Logistics and distribution
Do you already have a process mining event log? How to tell from your systems
By SourceX Editorial · Updated
Short answer
You already have a process mining event log if your systems record three fields for each step: a case ID that ties steps together, an activity name, and a timestamp. Many ERP, WMS and ticketing systems capture all three, often in audit, history or status-change tables rather than the screens people use every day.
Key takeaways
- An event log needs only three fields per row, case ID, activity and timestamp; everything else is an attribute.
- Status fields that are overwritten fail the test, while change logs and transaction histories usually pass.
- Choose the case ID from the question you want answered: order, order line, shipment or ticket.
- Posting dates and batch run times are not event times, so check whether time stamps record when the work happened.
- The same three fields show an AI developer that your records hold real workflow sequences, which matters in a licensing fit check.
The three-field test#
The three-field test asks whether each recorded step carries a case ID, an activity and a timestamp. The case ID groups steps into one instance of a process, such as a sales order or a support ticket. The activity names what happened. The timestamp says when it happened, ideally to the minute or second.
Other fields, such as the user, warehouse, customer type or cost, are attributes. They make analysis richer but are not required to build the log. If a system cannot supply the three core fields, no amount of extra attributes will turn its data into an event log.
| Field | ERP example | WMS example | Ticketing example |
|---|---|---|---|
| Case ID | Sales order number | Order or shipment number | Ticket number |
| Activity | Order created, credit hold released, invoice posted | Pick confirmed, packed, ship confirmed | Ticket opened, assigned, status changed, solved |
| Timestamp | Change log or document creation date and time | Transaction history date and time | Ticket audit or event time |
| Useful attributes | Customer, salesperson, order type | Picker, zone, carrier | Agent group, priority, channel |
Where the three fields hide in ERP, WMS and ticketing systems#
The three fields usually hide in history tables rather than main screens. A sales order screen shows the order as it is now; the change log or audit trail behind it shows each change, who made it and when. That history, not the current record, is the event log.
Ask IT or the system vendor which history tables exist, whether they are switched on, and how long they are retained. Some change logging is optional or configured field by field, so the answer can differ between two companies running the same software.
- ERP: document flow between quote, order, delivery and invoice, plus change logs on orders, credit holds and pricing.
- WMS: inventory transaction history covering receipts, putaway, moves, picks, adjustments and ship confirmations.
- TMS and carrier feeds: load events and status messages from tender to delivery.
- Ticketing and help desk tools: ticket audits or event streams with every status, assignment and field change.
- EDI logs: inbound and outbound documents with control numbers and processing times.
Why logs fail the test, and what to do about it#
Logs fail the test for a small set of repeatable reasons, and most can be spotted before anyone extracts a file. Walk through them with the person who administers each system, and note which failures can be fixed going forward and which permanently limit the history you already have.
| Failure | What it looks like | Fix or workaround |
|---|---|---|
| Overwritten status | Only the current status is stored | Turn on change logging now; usable history starts from that date |
| Dates without times | Several activities share a date with no order between them | Use a related table with full time stamps, or accept day-level analysis |
| Posting time, not event time | Batch jobs stamp many events at once | Find the original transaction time, or flag batch events |
| No shared case ID | Tickets do not carry the order number | Add a required reference field; link older history with matching rules |
| Free-text activities | The same step is written many ways | Map text values to a controlled activity list |
| Purged history | Old events deleted under retention settings | Check retention before any migration and export first |
| Mixed time zones | Sites record local time without a zone | Normalize to one zone and keep the original value |
Choosing the case ID when one order becomes many shipments#
The right case ID depends on the question being asked. Distribution and logistics processes split and merge: one order becomes several shipments, several orders ship on one load, and one ticket can cover many orders. A classic event log forces a single case ID, so each choice shows some steps clearly and distorts others.
Object-centric approaches, which keep orders, lines, shipments and tickets as separate linked objects, avoid forcing one choice. They need the same raw ingredients, though: every event must still carry identifiers and a timestamp.
- How long does order-to-ship take? Use the order number.
- Where do partial shipments come from? Use the order line.
- Why do loads miss pickup windows? Use the load or shipment number.
- How are customer complaints resolved? Use the ticket number, with order numbers as attributes.
A self-check your IT lead can run#
A self-check takes a handful of real cases and traces them through every system by hand. It is faster than any tool evaluation and shows exactly where the three fields break, before anyone commits budget to software or extraction.
- Pick one process, such as order-to-ship or exception-to-resolution.
- Choose a handful of recent cases, including at least one that went wrong.
- For each case, list every system that touched it and the ID used there.
- Pull every time-stamped event for each case from history or audit tables.
- Line the events up in order and note gaps, identical time stamps and missing links.
- Record which systems pass, which pass with fixes, and which fail.
Illustrative: a wholesale distributor checks its order-to-ship log#
Illustrative: a fictional wholesale distributor of industrial safety products and workwear runs an ERP for orders and invoicing, a separate WMS, and a help desk for customer service. The COO wants to know why some orders ship late and whether the data to find out already exists.
The IT lead traces several orders. The ERP change log records order entry, credit holds and releases with full time stamps. The WMS records picks and ship confirmations by user and time. Help desk tickets mention order numbers only in free text, so customer contacts join some orders and not others.
The distributor decides the order-to-ship log is good enough to analyze now and makes the order number a required ticket field going forward. The first analysis points to credit hold release, not picking, as the main source of delay, and the credit team changes its review routine.
Why the three fields matter in a data licensing fit check#
The three fields matter in a licensing fit check because AI developers building workflow and agent systems want records of real work in sequence: what happened, in what order, by which role, with what outcome. An event log is direct evidence that your systems hold those sequences rather than only final states.
In a SourceX fit check the questions are metadata only: which systems keep history tables, how far back they reach, and whether a shared case ID links them. If the work proceeds through the SourceX five-step transaction, preparation replaces employee user IDs and customer names with consistent tokens, since event logs often contain personal information about staff and contacts.
Frequently asked questions
Do we need process mining software to build an event log?
No. An event log is a table with one row per event and, at minimum, columns for case ID, activity and timestamp. It can be built with database queries or exports and a spreadsheet or script. Process mining tools help analyze and visualize the log once it exists.
Is an audit log the same as an event log?
Not exactly. An audit log records field changes, such as a status moving from open to picked, often in technical terms. Turning it into an event log means mapping those changes to business activities and choosing the case ID. Audit logs are usually the best raw source.
Can events from email or spreadsheets be included?
Sometimes. Emails carry reliable time stamps and can be linked to cases when they quote an order, shipment or ticket number. Spreadsheets rarely record when each change was made. Treat both as supporting events and mark them so their lower reliability stays visible.
Does an event log contain personal data?
Often, yes. User IDs, employee names and customer contacts appear as attributes, and which privacy laws may apply turns on whose data it is and where those people are. Pseudonymize users and remove contact details unless the analysis truly needs them, and review the intended use with counsel.
How much history does an event log need?
Enough to cover normal variation in the process you study, including seasonal peaks and, ideally, a period of disruption. For process improvement, recent history matters most. For AI training or evaluation, longer linked histories are usually more useful than a recent slice.
Related resources
- IndustryBPO & contact centers data
- IndustryIT managed services data
- QuestionDo AI labs buy video of people working?
- InsightCan property management companies sell their data to AI companies?
- InsightCan e-commerce brands sell their data to AI companies?
- InsightCan call centers and BPOs sell their data to AI companies?
See if your company qualifies
A short company assessment. No data uploads are needed.