Process trace

What is a process trace?

A process trace is the ordered sequence of events recorded for a single case in an event log. It shows which registered activities that case went through, and in what order.

For an order, the trace might read: order created, credit checked, goods shipped, invoice sent, payment received. For a support ticket it might read: received, assigned, customer contacted, reply received, resolved, closed. Each case has its own trace.

The trace is a data picture of what happened, not a full account of it. Steps that were never registered do not appear. A trace that looks complete in the tool is therefore not automatically a complete record of everything people actually did.

How a trace is built

The event log groups events by their case id. Within each group, the events are ordered by timestamp, and where needed by an extra sorting key.

A formal trace is often written as a plain sequence of activity labels. In practice, tools also keep event attributes, exact times, and the resource that carried out each step, which is what makes performance analysis and organisational analysis possible later on.

The same activity can appear more than once. A trace of document checked, document amended, document checked shows a rework loop: the case looped back to a step it had already passed.

Order when timestamps are equal

Two events can carry the same timestamp because the source only stores minutes or days, or because a batch job registered them at once. Without more information, their order relative to each other is simply unknown.

Use a sequence number, a log id, or lifecycle information if the source provides it. Do not fall back on sorting by activity name, because that invents process behaviour that was never observed.

Genuinely parallel events have no simple total order at all. A classic trace still forces them into a single line. A process model can represent that parallelism, but only if the log carries enough information to recognise it in the first place.

A worked ticket example

Ticket T-810 has the events received, assigned, customer contacted, reply received, resolved, closed. That forms one trace.

Ticket T-811 runs through received, assigned, forwarded, assigned, resolved, closed. The repeated assignment shows a hand-off between people. The two tickets have different traces, and variant analysis can group all tickets that share the same activity sequence and compare their waiting times.

Now suppose reply received only lives in email and never reaches the event log. The trace would make the whole wait look like it sat with the handler, when in fact part of it was time spent waiting on the customer. One missing event changes the interpretation.

Trace versus process instance and variant

The process instance is the real execution and its context: the actual order, with its amount, customer, and history. The trace is the recorded event sequence for that instance. One is the reality, the other is its footprint in the data.

A process variant groups traces by a chosen rule for sameness, most often the same activities in the same order. A hundred cases can therefore share a single variant. Attributes such as amount or customer type can differ while the activity sequence stays identical, and whether those count as separate variants depends on how the analysis defines it.

Traces in discovery and conformance

Process discovery uses a collection of traces to derive a process model. Frequency and ordering patterns decide which behaviour becomes visible in the map.

Conformance checking compares traces against the behaviour a model allows. Token-based replay and alignments are two techniques that locate the deviations and compute fitness from them. A trace with rare but valid behaviour should not be branded an error automatically; domain knowledge decides whether the route was legitimate, unwanted, or simply recorded wrongly.

What to watch out for with traces

Check for traces with a missing start or end event, an impossible order, an extreme length, or events that fall outside the extraction window. Open cases are often cut off on the right-hand side, so they look shorter than the work that is still running.

Do not filter out the longest or strangest traces just to get a tidy map. Investigate first whether they represent data errors, genuine exceptions, or real process problems. And keep the extraction and sorting rules under version control: when the definition changes, so do the variants, the fitness scores, and the performance results built on top of them.