Case ID

What is a case ID?

A case ID is the field in your event log that tells you which process run an event belongs to. Every activity in your data gets such an ID, and all events with the same ID form one case: one complete run of the process from start to finish.

In practice it is usually the object the process revolves around. For an order-to-cash process, that is the order number; for ticket handling, the ticket number; for a hospital admission, the patient file.

Without a case ID you do not have an event log, only a stack of loose actions. The case ID binds those actions into a story a tool can read.

How do you pick the right case ID?

The question is simple: what counts as one complete process run for you? The answer decides which column becomes your case ID.

• One case = one complete flow. The case ID holds all events from the first to the last step. No more, no less.

• The ID sits on every event. If it is missing on some steps, those events drop out of the analysis.

• The ID is stable. It does not change halfway through. If your order number changes the moment an invoice is generated, you have a linkage problem.

Your choice of case ID literally dictates what the tool treats as "one flow". Two different IDs on the same data produce two different process maps.

Examples by domain

Which column becomes the case ID depends on your process and sector.

• Retail and e-commerce: order number for order-to-cash, purchase order for purchase-to-pay.

• Support and IT: ticket ID for incidents, change ID for change management.

• Healthcare: patient file for an admission, appointment ID for a consultation.

• B2B services: contract number, project number or quote ID.

• HR: candidate ID for recruitment, request ID for leave or expenses.

The same data can contain several processes depending on which case ID you pick. Invoicing data under "customer number" gives you the customer journey; under "invoice number" you get the invoicing process itself.

What breaks when you pick the wrong one?

A wrong case ID breaks your analysis in one of two ways.

Too fine: your process falls apart. Take a back order where one order runs through several partial deliveries and invoices. Pick the invoice number as the case ID and the tool sees each invoice as a separate process. The chain from order to payment is gone.

Too coarse: you glue several processes together. Pick the customer number as the case ID for that same process and every order from that customer ends up in one case. The process map becomes a tangle with no stable pattern left to read.

There are also processes where one case ID per event is structurally not enough. An event can hang off an order, a delivery and an invoice at the same time, each with its own life. That is where object-centric process mining comes in: every event can attach to multiple objects at once, so you do not have to choose which dimension is the case. For most SMB processes, a classical case ID is enough.