How to choose a case ID in process mining: a practical guide

A case ID in process mining is the field that links events into a single run of a process. You choose it by asking which business object the process exists to handle. Then you check that the identifier appears on the relevant events, stays stable from start to end and is unique to each run.

• The case ID defines what counts as a single run of the process, so it shapes every map and metric.
• Start from the business object the process serves, such as an order, an invoice or a claim.
• A good case ID is present on the events that matter, stable over time and unique per run.
• Test candidate case IDs on a sample before committing, and check how complete each column is.
• When work happens outside the system that holds the case number, plan how to link it or study it separately.

What is a case ID in process mining?

A case ID in process mining is the identifier that groups events into cases. A case is a single run of a process from start to finish.

An event log records what happened, when it happened and to which case it belongs. Process mining tools order the events of each case by timestamp. The result is a path for each case, and the paths together form the process map.

Because every metric rests on that grouping, the case ID choice shapes what the analysis can tell you. Cycle time, throughput, variants and repeated loops all depend on where a case starts and ends.

A wrong case ID rarely triggers an error message. A wrong case ID produces maps that look plausible but describe the wrong thing, which is why the choice deserves deliberate attention.

Which business object should the case ID follow?

The case ID should follow the business object that the process exists to move forward. Ask what thing enters the process, gets worked on and leaves finished.

• Purchase-to-pay: the purchase order or the invoice, depending on your question.
• Order-to-cash: the sales order or the customer invoice.
• Claims handling: the claim number.
• Customer service: the ticket or service case number.
• Employee onboarding: the onboarding request for each new hire.

The question you want answered settles close calls. If your team worries about late payments, the invoice is usually the better case. If the concern is how long buying takes, the purchase order often fits better.

Teams sometimes analyze the same process twice with different case IDs. That approach works well when separate stakeholders ask separate questions, as long as each analysis states which case ID it uses.

What makes a good case ID?

A good case ID in process mining has a few qualities that your team can check before building any analysis. Use the list below as a screening test for each candidate identifier.

• Coverage: the identifier appears on the events that matter, across the systems the process touches.
• Stability: the value does not change between the initial step and the final step.
• Uniqueness: each value marks a single run, and values are not reused for later runs.
• Right granularity: a case is neither so broad that unrelated work merges nor so narrow that a run splits apart.
• Business meaning: process owners recognize the identifier and can look a case up in their own systems.

Coverage is often the hardest test. Many processes cross systems, and each system may label the same work with its own number. When that happens, teams build a mapping table that links the local numbers to a shared case ID.

Granularity needs judgment. An order with many lines can be treated as a case, or each line can be a case. Choose the level at which your team makes decisions and measures delays.

How do you test a case ID before you commit?

You test a case ID by building a small event log around the candidate and reading the results with process owners. A short test exposes most problems before the full analysis begins.

1. List candidate identifiers and the systems that store them.
2. Check how complete each candidate column is, and note the events where the value is blank.
3. Count events per case and look for cases with very few or very many events.
4. Read a handful of case timelines from start to finish and compare them with what process owners expect.
5. Scan the map for impossible paths, such as payment before approval.
6. Record the chosen case ID, the reasons for the choice and the known gaps.

Very short cases often signal a split: the same run carries different identifiers in different systems. Very long cases often signal a merge: a reused or overly broad identifier joins unrelated runs.

What if work does not carry a case ID?

Work without a case ID still matters, but that work needs extra handling before process mining can use it. Desktop steps, inbox handling and spreadsheet work often happen outside the system that holds the case number.

• Ask people to enter the case number when they start a task.
• Add the case number to the system record at the point where work begins.
• Correlate events by other attributes, such as customer and time window, and treat the result as an estimate.
• Leave unlinked work out of the case analysis and study that work separately at task level.

The difference between task mining vs process mining matters here: task-level data shows how a step is done, while case-level data shows how runs flow end to end.

How does Optimus Hive handle the case ID?

Favus process mining software builds its analyses from an event log file with three fields per event: a case ID, an activity and a timestamp. Resource, vendor, customer type and amount are optional.

A searchable case explorer in Favus shows each case's event timeline. A data preview shows each column's completeness.

In Opus task mining software, employees start, pause, resume and stop a task recording themselves, and can log exceptions. Opus tags that activity with the task and, where the employee enters one, a case ID.