What Is Object-Centric Process Mining (And What It Misses)

Object-centric process mining (OCPM) is an approach to process mining that links a single event to multiple business objects at once — an order, an order item, a shipment, an invoice — instead of forcing every event into one case. It exists because the older, case-centric approach quietly distorts the processes it is supposed to reveal.

If your order-to-cash analysis has ever produced a process map that looked tidier than the operation you recognise, this is why. And it is only half the reason.

What is object-centric process mining?

Object-centric process mining analyses processes by preserving the relationships between the business objects involved, rather than reducing each event to a single case identifier.

Traditional process mining starts by choosing a case notion: one order, one ticket, one claim. Every event is then tied to that one case. The result is a flat event log with three mandatory columns — a case ID, an activity, a timestamp — and a process model that describes the lifecycle of that case in isolation.

Object-centric process mining drops the single-case assumption. An event such as create shipment can relate to the shipment, to several order items, and to the original sales order simultaneously. Those relationships live in an object-centric event log, most commonly following the OCEL standard, structured as two connected tables: one for events, one for objects.

The academic groundwork comes from Prof. Wil van der Aalst, widely described as the godfather of process mining. Celonis was the first major vendor to productise the approach with Process Sphere in 2022, and van der Aalst called it the biggest step-change in the field in a decade. Microsoft has since shipped object-centric process mining in Power Automate, and SAP Signavio documents it as a standard technique. The concept is no longer emerging. It is becoming table stakes.

Why case-centric process mining distorts what you see

The single-case assumption does not merely simplify a process. It introduces two specific, named errors.

Convergence happens when one event gets duplicated across many cases. Pick sales order item as your case notion, and an order-level event like place order is copied onto every item in that order. One event becomes twelve. Volumes inflate, and every metric built on them is wrong.

Divergence is the mirror image. Pick sales order as your case notion, and item-level events collapse into one another. Pick item and pack item happen once per item, in a fixed sequence. Flattened to order level, they appear to repeat in no particular order. Your process map shows loops and rework that never happened.

Neither error announces itself. The model renders, the dashboard loads, the numbers look plausible. That is exactly what makes them expensive.

There is a practical cost on top. Every new question needs a new case notion, and a new case notion means a new extraction. What is the most common reason for a blocked order? needs sales orders as cases. Which customers pay late? needs invoices. Same systems, same underlying data, another round of extraction and transformation — the same dependency that makes classic process mining projects run for months rather than days.

Object-centric process mining vs traditional process mining

The difference between object-centric and traditional process mining is what each treats as the unit of analysis: a case, or a network of related objects.

• Unit of analysis. Case-centric: one case per event. Object-centric: many objects per event.
• Event log. Case-centric: a flat table with one case ID. Object-centric: an object-centric event log holding events and objects separately.
• Object relationships. Case-centric: lost in flattening. Object-centric: preserved.
• A new question. Case-centric: a new extraction. Object-centric: a new view on the same data.
• Convergence and divergence. Case-centric: a structural risk. Object-centric: largely avoided.
• Best suited to. Case-centric: linear processes with one clear lifecycle. Object-centric: processes where objects split, merge and interact.
• Data preparation. Case-centric: lower effort. Object-centric: higher — the object model has to be defined.

Case-centric mining is not obsolete. For a support ticket, a leave request or an insurance claim, one case explains most of the flow and the simpler model is the better model. Object-centric mining earns its added complexity where processes genuinely branch across objects — order-to-cash being the canonical example, alongside procurement and manufacturing. Microsoft's own guidance is that many teams run both: case-centric for a crisp single-instance view, object-centric when the insight depends on how objects relate.

How an object-centric event log works

An object-centric event log describes two things separately, then connects them.

The events table holds each event with an identifier, an activity, a timestamp and — critically — the objects it touched. The objects table holds each object with an identifier, a type such as sales order item or customer, and its own attributes.

For a single order-to-cash flow, the relationships look like this:

• Create sales order relates to the sales order and its order items.
• Confirm item relates to a single order item.
• Create shipment relates to the shipment and to several order items.
• Issue invoice relates to the invoice and the sales order.
• Return item relates to an order item and a shipment.

Because objects stay separate but linked, you can ask whether items from one order followed different paths, whether invoices went out before everything shipped, or whether a return touched only part of the order. Under a single case notion each of those needs its own extraction. Here they are all views on one model.

Where object-centric process mining still falls short

Object-centric process mining fixes the object problem. It does not fix the communication problem — and in most enterprises the communication problem is bigger.

Look closely at what qualifies as an object in an OCEL. A sales order. An order item. A shipment. An invoice. Every one is a record that already exists in a system of record. The object model is built from ERP and CRM tables, which means object-centric process mining sees exactly as much of your process as your transactional systems happened to write down.

Now consider how an order actually changes. A customer emails to move a delivery date. A colleague forwards it with "can you check whether this still fits?" Someone opens SAP, looks at stock, decides it does not fit, replies with an alternative, and updates the order two days later.

In the object-centric model that entire sequence produces one event: the order was updated. Timestamp, done. The two days sit in the model as unexplained duration on a single object. The reason for the delay — a decision made in an inbox, by a person, using judgment that was never written to a table — is not a missing attribute. It is not an object at all.

This is not an edge case. In communication-heavy operations most exceptions begin as a message, and exceptions are where the time goes. A process model built only from system records will faithfully reproduce the happy path and stay silent about the part that costs money.

That is the gap conversation mining closes. Custom-trained AI models read incoming messages, identify intent, extract the relevant business data and turn them into operational signals that enter the same process model as the system events. The communication layer stops being invisible context and becomes part of the measurable process. Tekst approaches the multi-object problem from this direction rather than through an object-centric event log — not a different notation for the same structured data, but a wider set of inputs feeding the process intelligence layer.

Structuring objects is not the same as structuring the problem

Van der Aalst makes a specific argument for why OCPM matters now: it is what makes enterprise AI tractable. Replace a "super complicated reality" with something structured, he says, and you can finally apply machine learning to it. His closing question is a good one — how are you going to apply AI without first structuring the problem?

He is right, and the argument is incomplete in a way that matters for anyone deploying agents.

An object model structures the objects. It does not structure the reasoning that moved them. An agent operating on an object-centric model knows that an order was updated. It does not know that the customer had already asked twice, that this account carries a standing exception, or that the last person to touch it ruled out a substitution for a reason they explained in an email and nowhere else.

Gartner has predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, citing unclear business value and inadequate risk controls among the causes. The pattern behind that number is consistent: agents perform well on a clean, narrow problem and fail when they meet the actual shape of the work. Give an agent objects without the communication that surrounds them and it will act confidently on half a process.

Which is also why seeing and doing are no longer separable. Object-centric process mining, like process mining before it, ends at analysis. Something still has to act — and if the only thing acting is a person reading an inbox, the model has described your bottleneck rather than removed it. Tekst is built the other way round: the process model feeds execution directly, and execution data feeds back into the model.

Do you actually need object-centric process mining?

Microsoft and SAP Signavio both offer sensible guidance here, and it comes down to the same two tests. A third one is usually missing.

Does one process instance genuinely involve several objects with their own lifecycles?

If an order routinely produces multiple items, shipments and invoices that behave independently, yes. If your process is one ticket from open to closed, case-centric is the right tool and object-centric modelling adds complexity you will pay for without return.

Are you willing to build and maintain an object model?

This is the part that gets understated. Preserving relationships means defining object types, events and links correctly, and keeping those definitions consistent as systems change. Extraction happens once instead of per question, which is a genuine gain — but the modelling work moves rather than disappears, and a weak object model produces a view nobody trusts.

Where does your process actually start?

This is the one that rarely gets asked. If most exceptions arrive as a message before they become a record, the object model will not contain your problem no matter how well you build it. Fixing the case notion when the real gap is the communication layer is precise work on the wrong half of the process.

‍

From seeing objects to running processes

Object-centric process mining is a real improvement on a real flaw. Convergence and divergence are not theoretical, the single-case assumption does distort complex processes, and keeping object relationships intact produces a more honest picture of how work moves.

It is also still a picture — of the part of your operation your systems wrote down. The order changed by email, the exception resolved in a side conversation, the approval that took two days because someone was waiting on an answer: none of that is an object, and none of it appears in the model.

Both halves have to be visible before automation is safe. The objects, and the conversations that move them.