Case notion

What is a case notion?

A case notion is the definition of what counts as one process run in a process mining analysis. It decides which events get the same case ID and are pulled together into a single trace.

For an order process, the case could be an order, an order line, a delivery, or a customer request. Each choice answers a different question.

So a case notion is not just a technical column. It fixes the boundaries of the analysis and the assumptions you make about what a single process run really is.

Case ID versus case notion

The case notion is the business concept. The case ID is the concrete key that identifies each run. With the notion Order, the OrderNumber column might serve as the key.

That same source column can quietly break. If order numbers are reused per region or reset each year, the key stops being unique on its own, and unrelated runs get merged. Write down the notion, its key fields, its start and end criteria, and the period it is valid for.

An example with order, item, and delivery

One order contains three items. Two ship in a first delivery and one in a second. A single payment covers the whole order.

With the order as the case, both deliveries sit in one trace. That works well for total lead time to the customer, but it makes the parallel item flows hard to read.

With the item as the case, the ordering and payment events may have to be copied across three traces. With the delivery as the case, there is no natural home for the one shared payment. The same raw events, three notions, three different pictures.

Convergence

Convergence happens when one event ends up inside several cases. A single payment, for example, gets copied onto every order line it settles.

Event and activity counts then inflate, and the map can show direct-follows steps that only exist because the same shared event appears in many traces. Giving the copies fresh IDs does not fix this. The event is still semantically duplicated, only now it is harder to notice.

Divergence

Divergence happens when events from several object instances are forced into one case. Two parallel deliveries under one order get stacked into a single artificial sequence.

A directly-follows graph can then draw arrows that exist only because two independent flows were interleaved, not because one step truly depends on the other. Splitting the case or choosing a finer notion can help, though it may create convergence somewhere else.

Where a case starts and ends

A customer relationship can run for years, which is usually too wide to be a useful case. A support ticket can reopen: is that the same case or a new one?

Use business rules for the start, the end, timeouts, and reopening rather than a calendar cut, which can chop long-running cases in half. Flag the cases that are incomplete at the edges of your extraction window so they do not distort duration figures.

Case notion versus process instance

A process instance is one concrete run of the process as you have defined it. In a simple process it lines up with one natural business case, so the two feel identical.

The term case notion exists to stress that the analyst constructs that unit from the data. The source systems may hold no explicit end-to-end run at all. That is why a report should not use the word case as if its meaning were obvious.

The object-centric alternative

Object-centric event data links an event to several objects at once, so you do not have to pick one universal case up front. An analysis can then follow the lifecycles of order, item, delivery, and invoice together and study how they interact.

This is the ground that object-centric process mining works on. It still needs modelling choices: which object types, relationships, and qualifiers you record decide what becomes visible. It is not an automatic cure for weak event correlation.

Choosing a notion

Start from the process question and the outcome you care about, then take the smallest meaningful unit that supports a clear start, end, and owner. When different questions need different notions, build more than one view instead of stretching a single one.

Validate the choice against domain experts and real source records, and state it plainly next to every result. Two analyses that counted different case notions cannot be compared as if the cases were the same.