Process instance

What is a process instance?

A process instance is one run of a process from start to finish: one order that goes from entry to payment, one insurance claim, one support ticket. It is the case that process mining talks about.

In classic process mining each instance gets a case ID. Every event carrying that identifier is grouped together as part of the same run and put in time order. The instance is the real file or journey inside the organisation; the trace is the recorded sequence of events that shows up in the event log, and that trace can be incomplete when systems do not log every step.

Choosing where a case starts and ends

Before you can group cases, you have to decide the boundaries. In order-to-cash the instance might start at "order placed" and end at "payment received". The boundary depends on the question. A return could be part of the original order case or a separate after-sales case, and both choices are valid but answer different things.

Write the start, the end, and any exclusions down. Otherwise analysts end up comparing cases that mean different things under the same label.

Case ID and correlation

The case ID is the key that ties events to an instance. It should be stable and unique within the analysis. An order number looks obvious, but one order can have several deliveries and invoices. Choose the invoice number and one order gets split across cases; choose the order number and parallel sub-flows collapse into one case.

Correlation often has to cross several tables and systems. You need to be able to show how each event was matched to its case ID, because a wrong join puts events on the wrong instance. This is where data lineage earns its keep.

A worked claim example

An insurer uses claim number CL-2048 as the case ID. The instance starts at "claim received" and runs through "documents checked", "assessment requested", "decision made", and "payment made".

Case attributes describe the instance as a whole, such as product, claim amount, and channel. Event attributes belong to a single step, such as the handler or the outcome of a check. If the assessment report lives in a separate system, a shared claim reference links its events back; without that reference, name or timestamp alone is usually too shaky to match automatically.

Process instance versus trace

The instance is the real execution, with its context and current state. The trace is its ordered event representation in the log. Two instances can have the same trace when they go through the same activities in the same order, and cases that share a trace fall into the same process variant. They stay separate all the same, through their case ID and attributes. A trace can also end while the instance is still open, for example because extraction stopped on a cut-off date, so mark open and finished cases apart.

What to watch out for with process instances

Check for empty and duplicate case IDs, for cases that are unexpectedly long or short, and for events outside your chosen boundaries. Compare counts against the source systems. Keep open cases out of throughput-time figures for finished work, or they will drag the numbers.

Above all, remember that choosing the process instance is a modelling decision, not a technical detail. In object-centric process mining there may be no single object that stands for the whole instance, because events can belong to orders, order lines, invoices, and deliveries at once. Use the classic single-case model when one stable boundary answers the question well, and go object-centric when many-to-many relationships are a real part of the process.