Deep Dive: Cardinalities

Cardinalities in process graphs provide critical structural insight into how activities relate to one another across case instances. They describe the multiplicity of transitions between activities—whether flows are strictly linear, branching, merging, optional, or iterative. By interpreting cardinality patterns such as 1:1, 1:n, or n:m, analysts can detect split-merge behavior, identify looping structures, uncover optional paths, and better understand structural complexity within business processes. This makes cardinality analysis an essential tool for diagnosing process design, performance dynamics, and exceptional execution patterns.

Understanding Cardinalities in Process Graphs

Cardinalities in process graphs help you understand the structural relationship between different activities across case instances. They describe how many times an activity transitions to another activity – in other words, whether it’s a one-to-one, one-to-many, or many-to-many relationship.

This concept is essential when analyzing recurring behaviors, split-merge patterns, or exceptional flows in business processes.

What does a Cardinality represent?

Each arrow in the process graph can include a cardinality label like 1:1, 1:n, or 0…1:1, describing the minimum and maximum amount of connections between two activity types, across all case instances.

The format is always:

[Source multiplicity] : [Target multiplicity]

Common Types of Cardinalities

Here’s a breakdown of the most common patterns:

1:1 – One-to-One

Each instance of the source activity is followed by exactly one target activity, and vice versa.

Interpretation: This path is executed once per case and shows a strong linearity.

Example: Schaden anlegen → Schaden einpflegen
1:1 means each created claim has exactly one follow-up step.

1:n – One-to-Many

One source activity leads to multiple instances of the next activity.

Interpretation: A single event triggers several follow-up actions.

Example: dbo.TypeC → dbo.TypeE
Cardinality like 1:0…3 means: one TypeC event can lead to up to 3 TypeE events.

n:1 – Many-to-One

Multiple source activities lead to the same target activity.

Interpretation: A consolidation point – different branches merge into one step.

Example: dbo.TypeB → dbo.TypeC with 1…2:0…1
This means: multiple TypeB events can lead into one TypeC.

n:m – Many-to-Many

Multiple events on both sides interact with each other.

Interpretation: A looping or repeating structure, such as rework or batch processing.

Example: You’ll see values like 1…2:0…2, meaning each side has multiple mappings – often seen in complex service processes or when “retries” occur.

0:1 / Optional Flows

A 0 indicates that the transition might not always occur.

Example: dbo.TypeE → dbo.TypeF with 0…1:0…1
Some cases skip this step entirely.

Practical Use Cases

Identify splits in process logic (e.g. invoice → multiple dunning steps)

Spot merges from parallel processing (e.g. approvals → finalization)

Detect optional paths and edge cases

Evaluate looping behavior in service or rework processes

Optimize resource planning by understanding bursty or linear transitions