---
title: "BPMN Modelling — Practical Guide: Requirements and Criteria for Building a Quality Process Model"
type: synthesis
tags: [bpm, bpmn, modelling, requirements, criteria, practical, construction, builder-guide, methodology]
sources:
  - "[[sources/2018-dumas-fundamentals-of-bpm]]"
  - "[[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]]"
  - "[[sources/2010-mendling-reijers-vanderaalst-7pmg]]"
  - "[[sources/1998-vanderaalst-verification-of-workflow-nets]]"
  - "[[sources/2006-krogstie-sindre-jorgensen-revised-sequal-framework]]"
  - "[[sources/2012-ottensooser-graphical-vs-textual]]"
created: 2026-05-04
updated: 2026-05-04
---

# BPMN Modelling — Practical Guide: Requirements and Criteria for Building a Quality Process Model

The **constructive counterpart** to [[syntheses/process-model-quality-and-soundness-evaluation-guide]]. The evaluation guide tells you how to assess an existing model; this guide tells you how to **build** one. It is organised as the analyst will actually work — from input preparation through element-level rules to validation gates.

Audience: process analysts, business analysts, and BPMN modellers producing **as-is or to-be process models** for documentation, redesign, simulation, or executable workflow specification. The guide assumes BPMN 2.0 syntax.

For the upstream interview/elicitation methodology that produces the raw material this guide structures into a model, see [[syntheses/interview-structuring-for-process-models]]. For evaluation of the finished product, see [[syntheses/process-model-quality-and-soundness-evaluation-guide]]. Together the three documents form the **discovery → modelling → evaluation** chain.

---

## 1. Inputs you must have before modelling

Modelling without sufficient inputs produces speculative diagrams. The following are **mandatory inputs** before opening the modelling tool:

### 1.1 Scope definition (TRAC)

Per [[sources/2014-sharp-using-scope-models]] the model's scope must be defined as **TRAC**:

- **Trigger(s)** — what event(s) initiate the process. List them all (a complaint can arrive by phone, email, letter, in-person — that's four triggers, one process).
- **Result(s)** — what end-states the process produces. List them per stakeholder (customer sees one outcome, finance sees another, compliance sees a third).
- **Activities** — 5±2 milestone activities between trigger and result. Not the full activity list — just the *spine*.
- **Cases** — the unit of work (one customer order, one insurance claim).

Without TRAC, you have no scope contract; the model will grow indefinitely.

### 1.2 Stakeholder roster

Cover at minimum:
- **Customer** (or external receiver of process output)
- **Every participant role** that performs activities
- **Process owner** (manager accountable for the process)
- **External parties** (suppliers, sub-contractors, partners) where relevant

The roster determines lane structure (see §11).

### 1.3 Source material

- Interview notes / transcripts (per [[syntheses/interview-structuring-for-process-models]] §2)
- Document analysis: policies, forms, work instructions, system screens (Dumas §5.2.1)
- Existing process documentation (if any) — flag explicitly as "as documented" vs "as performed"
- Observation notes (if observation method used)

### 1.4 Modelling goal — the load-bearing input

State the modelling goal **before** drawing. Per [[sources/2018-dumas-fundamentals-of-bpm-ch3-essential-process-modeling]] §3.1, BPMN models split into two fundamentally different categories:

| Category | Purpose | Audience | Contents | Used for |
|---|---|---|---|---|
| **Conceptual model** | Organisational design | Process owners, business analysts, participants | Activities, events, gateways, lanes — no IT details | Discovery, communication, analysis, redesign basis |
| **Executable model** | Application system design | System engineers, solution architects, developers | Plus data types, mappings, service tasks, system interfaces | BPMS deployment, software development |

The same business process may need *both*: a conceptual model for stakeholder alignment and an executable derived from it for automation (Dumas Ch. 10).

Different goals require different quality emphases:

| Goal | Quality priority | BPMN constructs to emphasise |
|---|---|---|
| **Documentation** | Pragmatic + semantic validity | Lanes, plain activities, rainy-day paths |
| **Compliance evidence** | Completeness + soundness | Boundary events, message flows, data objects |
| **Redesign baseline** | Validity + complexity metrics | Detailed gateways, performance annotations |
| **Simulation** | Soundness + quantitative annotations | Frequencies, durations, branch probabilities |
| **Executable workflow** | Soundness + executable BPMN | Service tasks, user tasks, DMN-linked rules, error events, data mappings |
| **Training material** | Pragmatic only | Few elements, large icons, narrative-friendly |

The goal also determines **decomposition depth**: a documentation model rarely needs sub-processes; an executable model often needs three levels.

### 1.5 Modelling tool

Choose deliberately:

- **Camunda Modeler / bpmn.io** — open-source, executable BPMN 2.0 XML, real-time validation. Recommended default.
- **Signavio (SAP)** — commercial; rich validation and collaboration; soundness checking.
- **Bizagi Modeler** — free, popular in business contexts.
- **Visio with BPMN stencils** — discouraged: produces non-validating diagrams.
- **PowerPoint / Lucidchart / draw.io** — discouraged: produces drawings, not models.

Validate that your chosen tool exports BPMN 2.0 XML. If it doesn't, you have a drawing, not a model — downstream integration is impossible.

---

## 2. The BPMN element catalogue — what to use when

BPMN is a large notation. Most processes are modelled with a small subset. The catalogue below covers what you actually need; advanced constructs are flagged.

### 2.1 Flow objects (must use)

| Symbol | Element | Use for |
|---|---|---|
| ○ thin circle | Start event (none) | Untyped start (any of the typed forms below preferred when known) |
| ◎ thick circle | End event (none) | Untyped end |
| ○ thin double | Intermediate event | Mid-process trigger or wait |
| Rounded rectangle | Task / Activity | One unit of work |
| Rounded rect + (+) | Sub-process | Decomposable activity |
| ◇ XOR | Exclusive gateway | One-of-N choice |
| ◇ + | Parallel gateway | All-of-N concurrency |
| ◇ O | Inclusive gateway | Some-of-N (caveat: 7PMG G5) |
| ◇ ⬠ | Event-based gateway | Race between event arrivals |

### 2.2 Typed events (use when applicable)

For start, intermediate, and end events, BPMN provides type markers. Typed events are **always preferred over untyped** when the trigger/outcome is known:

| Type marker | Start | Intermediate | End |
|---|---|---|---|
| Message ✉ | Triggered by message arrival | Wait for or send message | Send final message |
| Timer ⏰ | Scheduled / cyclic start | Delay / deadline | (rare) |
| Error ⚡ | (only in event sub-process) | (boundary/sub-process) | Throw error |
| Signal 📡 | Broadcast received | Wait for / throw broadcast | Throw broadcast |
| Conditional ☰ | Triggered when condition true | Wait for condition | (rare) |
| Escalation ↗ | (only in event sub-process) | Throw / catch escalation | Throw escalation |
| Compensation ↩ | — | Trigger compensation | Trigger compensation |
| Terminate ⊗ | — | — | Force-end all instances of process |
| Multiple ⬟ | Triggered by any of N | Wait for any of N | Throw N events |

### 2.3 Activity types (use when applicable)

Within a task, BPMN distinguishes:

| Type marker | Meaning |
|---|---|
| User task 👤 | Performed by a human via UI |
| Manual task ✋ | Performed by a human without IT support |
| Service task ⚙ | Automated by an external service |
| Send task ✉→ | Sends a message |
| Receive task ✉← | Receives a message |
| Script task 📝 | Inline script execution |
| Business rule task 📋 | Decision invocation (typically [[frameworks/dmn]]) |

For **descriptive (non-executable) models**, type markers are optional but recommended for documentation clarity. For **executable models**, type markers are mandatory.

### 2.4 Connecting objects

| Object | Connects | Crosses pool? |
|---|---|---|
| **Sequence flow** (solid arrow) | Flow elements within a pool | No |
| **Message flow** (dashed arrow with open arrowhead) | Pools (between participants) | Yes — only |
| **Association** (dotted line) | Annotation/data ↔ flow object | n/a |
| **Data association** (dotted arrow) | Activity ↔ data object | n/a |

### 2.5 Swimlanes

| Element | Use for |
|---|---|
| **Pool** | One participant (organisation, system, role at organisational level) |
| **Lane** | Subdivision of pool — typically a role, department, or system |

### 2.6 Artifacts

| Element | Use for |
|---|---|
| **Data object** | Information item produced/consumed by an activity (transient) |
| **Data store** | Persistent data (database, file system) |
| **Annotation** | Free-text comment attached via association |
| **Group** | Visual grouping (no semantic meaning) |

### 2.7 Sub-process variants (Chapter 4 / executable)

| Marker | Meaning |
|---|---|
| Plain `+` | Embedded sub-process (decomposed in same pool) |
| Embedded with start/end events | Same — explicit boundary |
| Call activity (thick border) | Reusable sub-process invoked from this point |
| Multi-instance `‖` (parallel) or `≡` (sequential) | Loop construct |
| Loop ↺ | Standard loop |
| Compensation ↩ | Compensable sub-process |
| Event sub-process (dashed boundary) | Triggered by interrupting/non-interrupting event in parent |

---

## 3. Mandatory structural requirements

These rules are **non-negotiable**. Violating them produces an invalid BPMN model.

### 3.1 Process boundaries

- **Exactly one start event** per process (per [[concepts/7pmg]] G3).
- **Exactly one end event** per process — or, if multiple distinct outcomes are essential, one end event *per outcome* with *clearly distinguishable labels* (e.g. "Order fulfilled", "Order cancelled", "Order rejected"). Multiple end events that represent the same outcome are forbidden.
- **No dangling flow elements** — every node must lie on some path from start to end (this is the WF-net condition (ii) — see [[concepts/workflow-net]]).

If interviews reveal multiple genuinely different triggers (phone, email, in-person), use **one start event** followed by an XOR gateway to capture the channel — *not* multiple start events. This satisfies G3 and produces a free-choice net (see §6.2).

### 3.2 Sequence flow rules

- Connect flow elements only (events, activities, gateways).
- Cannot cross pool boundaries — use message flow.
- Cannot connect to data objects, annotations, or directly between pools.
- Each task should have **exactly one incoming and one outgoing sequence flow** unless explicitly using a gateway. Multiple incoming flows on a task creates an *implicit join* with ambiguous semantics — make the join explicit.

### 3.3 Gateway rules

- Every split gateway must have a matching join gateway of the same type ([[concepts/7pmg]] G4 — structuredness).
- XOR splits must be **mutually exclusive and exhaustive**: conditions cover all cases without overlap. Use a default flow (marked with /) for the catch-all branch.
- AND splits must wait for *all* incoming branches at the join.
- OR gateways are discouraged (G5). If you must use one, document the inclusive semantics in an annotation.
- Gateways are routing devices, not work units — they don't perform activities. Do not put process logic *inside* a gateway label.

### 3.4 Pool and lane rules

- Each task assigned to exactly **one** lane.
- A pool encapsulates one participant's process — never split a single process across pools.
- Message flows cross pool boundaries; sequence flows do not.
- For black-box participants (where you don't model the internal flow), use an empty pool with only start/end events visible at message-flow boundaries.

### 3.5 Behavioural correctness — soundness and the four anomalies

The model must satisfy classical [[concepts/soundness]]:

1. **Option to complete** — every reachable state can reach the end event.
2. **Proper completion** — when end event fires, no orphan tokens remain (Dumas's BPMN-specific formulation: each token must reach a *different* end event).
3. **No dead transitions** — every activity is executable from some reachable state.

#### The four behavioural anomalies (Dumas §5.4.1)

A sound model contains *none* of these. Verifying soundness = checking the absence of all four:

| Anomaly | Symptom | Caused by | Violates |
|---|---|---|---|
| **[[concepts/deadlock]]** | Token stuck; instance never completes | XOR-split → AND-join (most common); branch injection into AND-block | (1) option to complete |
| **[[concepts/livelock]]** | Token cycles in a loop forever | Loop with always-true exit; loop with no exit gateway | (1) option to complete |
| **[[concepts/lack-of-synchronization]]** | Multiple tokens on same flow; activity executes twice | AND-split → XOR-join (most common); OR-split → XOR-join | (2) proper completion |
| **[[concepts/dead-activity]]** | Activity never executable | Provably-false branch condition; downstream of a deadlock; disconnected fragment | (3) no dead activities |

[[concepts/token-semantics]] — these anomalies are best reasoned about at the token level. The split/join token rules (XOR routes one, AND spawns N, OR spawns k≤N) determine which combinations are anomaly-free.

#### [[concepts/block-structure|Block structure]] — sound by construction

If you build the model using only nested blocks of matching split-join type (AND-AND, XOR-XOR, OR-OR), **no anomaly can arise within blocks**. This is the simplest path to behavioural correctness.

| Pattern | Anomaly risk |
|---|---|
| AND-split + AND-join (matched block) | None within block |
| XOR-split + XOR-join (matched block) | None within block |
| OR-split + OR-join (matched block, synchronising merge) | None within block |
| AND-split + XOR-join (mismatched) | Lack of synchronisation |
| XOR-split + AND-join (mismatched) | Deadlock |
| Loop with mismatched entry/exit gateways | Livelock + lack of synchronisation |

**Built-in compliance**: if you build the model using only the structured patterns in §6 (sequence, parallel split-join, exclusive split-merge, structured loop) and respect §3.3 split-join matching, the model is **sound by construction**. Each pattern corresponds to a soundness-preserving transformation rule per [[sources/1998-vanderaalst-verification-of-workflow-nets]] §5 (Theorem 18, Corollary 19).

#### When block structure is too restrictive

Some legitimate cyclic patterns and event-driven structures cannot be expressed in block-structured form ([[sources/2018-dumas-fundamentals-of-bpm]] §4.1). For those:
- Build the model freely.
- Run a [[concepts/soundness|soundness checker]] (WOFLAN, ProM) before sign-off.
- Document the unstructuredness rationale in an annotation.

Most administrative and transactional processes can be built block-structured. Knowledge-intensive or compliance-driven processes may need declarative models ([[frameworks/declare]]) or unstructured BPMN.

---

## 4. The five-step modelling method

Per [[sources/2018-dumas-fundamentals-of-bpm]] §5.3 — the disciplined order of operations. Following these in order avoids most rework:

### Step 1 — Process boundaries
Place start event(s) and end event(s). Annotate with the trigger names and the result names from your TRAC scope. **Do not** add anything else yet.

### Step 2 — Activities and events
Enumerate the *main business activities* between start and end. Aim for the **5±2 milestone** activities that came out of TRAC. Add any intermediate events you know about (timers, message catches). Defer fine detail.

### Step 3 — Resources and handoffs
Place pools and lanes. Assign each activity to a lane. Mark every **handoff** (sequence flow crossing lane boundaries) — these are points where you'll need to validate against the receiving role's interview separately.

### Step 4 — Control flow
Add gateways. For each branching point: identify the type (XOR/AND/OR), the conditions (for XOR), the synchronisation (for AND). Add loops. **At this step, run a soundness sanity-check** — every split has a matching join, no dead branches.

### Step 5 — Additional elements
Add data objects, message flows, exception handlers, compensation, annotations. Include only what the modelling goal requires (§1.4).

**Anti-pattern**: trying to do steps 2–5 in one pass produces a tangled diagram. The five-step discipline forces correct layering.

---

## 5. Naming and labelling standards

Labels carry most of the model's information for human readers. Bad labels sink pragmatic quality regardless of structural correctness.

### 5.1 Activity labels — verb-object (G6)

The single most evidenced rule ([[sources/2010-mendling-reijers-vanderaalst-7pmg]] §3.2 — n=29 experiment): **verb-object** labels are significantly less ambiguous and more useful than alternatives.

✅ Good: *"Send invoice"*, *"Approve loan"*, *"Inform complainant"*, *"Verify identity"*, *"Register customer"*

❌ Bad — action-noun: *"Invoice sending"*, *"Loan approval"*, *"Complainant information"*

❌ Bad — noun only: *"Invoice"*, *"Loan"*, *"Complaint analysis"*

❌ Bad — passive: *"Invoice is sent"*

❌ Bad — process-name-as-activity: *"Order management"* (this is a process, not an activity)

❌ Bad — composite: *"Verify and approve and notify"* (split into three activities)

**Rules of thumb** (refined per [[sources/2018-dumas-fundamentals-of-bpm-ch3-essential-process-modeling]] §3.1):
- Use **active voice**, **imperative form** of the verb.
- Verb may be followed by an adverbial clause to explain *how*: *"Renew driver license via offline agencies"*.
- Object may be preceded by an adjective: *"Issue driver license"* → *"Issue temporary driver license"*.
- **Max 5 words** excluding prepositions and conjunctions — keeps labels readable.
- Replace **generic verbs** (*to make, to do, to perform, to conduct*) with specific verbs that capture the activity's specifics: *"Verify"*, *"Validate"*, *"Approve"*, *"Reject"*, *"Notify"*, *"Archive"* are better than *"Process"*, *"Handle"*, *"Manage"*.
- **Pick a part of speech and stick to it**: words like *"process"* or *"order"* should be used **either as verbs or as nouns within one model, not both** — mixing creates ambiguity.
- Object should be **singular and concrete**.
- Capitalise the first word of activity and event labels.
- **8–40 characters** is a typical comfortable range. If your label exceeds 60 characters, you're describing two activities.

### 5.2 Event labels — past participle / state

Events represent **states of the world** or **occurrences**. Use noun phrases describing the state:

✅ Good: *"Order received"*, *"Payment confirmed"*, *"Invoice sent"*, *"Deadline expired"*, *"Customer registered"*

❌ Bad — verb form: *"Receive order"* (that's an activity)

❌ Bad — generic: *"Event occurred"*, *"Trigger"*

For typed events, the label should describe the *state*, not the type:

- Message event labelled *"Order received"* (not *"Order message"*).
- Timer event labelled *"15 days elapsed"* or *"After business hours"* (not *"Timer"*).
- Error event labelled *"Validation failed"* (not *"Error"*).

### 5.3 Gateway labels

Two valid forms:

**Question form** for XOR: *"Order valid?"*, *"Customer eligible?"*, *"Stock available?"* — branch labels are then the answers (*"Yes"*, *"No"*, or specific values).

**Noun-condition form**: gateway has no label; each outgoing branch is labelled with the condition (*"Amount > 10000 €"*, *"VIP customer"*, *"Default"*).

For AND splits/joins: typically unlabelled — the parallelism is structural, not conditional.

For event-based gateways: unlabelled — the events themselves carry the racing semantics.

### 5.4 Lane and pool labels

- **Pool**: name of participant — organisation, role-at-organisation level, or external party. Examples: *"Customer"*, *"Bank ACME"*, *"Logistics Provider"*.
- **Lane**: subdivision of pool — role, department, or system. Examples: *"Account Manager"*, *"Credit Department"*, *"CRM System"*.

A lane named *"Various"* or *"Misc"* is a smell — it usually means you have multiple roles you didn't disambiguate.

### 5.5 Data object labels

Format: **noun + state** in square brackets.

✅ Good: *"Application [submitted]"*, *"Application [approved]"*, *"Invoice [draft]"*, *"Invoice [signed]"*

The state changes track the data object's lifecycle through the process. The same data object appearing twice with different states (*"Application [submitted]"* → *"Application [verified]"*) communicates the transformation more clearly than two separate objects.

### 5.6 Sub-process labels

Same rule as activities — verb-object. The sub-process name describes what the sub-process **does** as a whole.

✅ Good: *"Verify customer"*, *"Process payment"*, *"Handle complaint"*

❌ Bad: *"Sub-process A"*, *"Customer subroutine"*

### 5.7 Annotation labels

Free text. Use for:
- Clarifying gateway conditions when the branch label can't carry the full condition.
- Documenting modeller decisions (*"Frequency: 5% of cases"*).
- Flagging uncertainty (*"? — pending validation with finance"*).
- Linking to external documents (*"See policy PR-2024-08"*).

### 5.8 Naming convention summary

| Element | Convention | Example |
|---|---|---|
| Activity | Verb-object, active voice, imperative | *Send invoice* |
| Sub-process | Verb-object | *Process payment* |
| Start event | Past-participle/state describing trigger | *Order received* |
| Intermediate event | State or trigger description | *Payment confirmed* |
| End event | State describing outcome | *Order fulfilled* |
| XOR gateway | Question (or unlabelled with branch conditions) | *Customer eligible?* |
| AND gateway | Unlabelled | — |
| Branch from XOR | Answer or condition | *Yes* / *No* / *Amount > 10K€* |
| Pool | Participant name | *Bank ACME* |
| Lane | Role / department / system | *Credit Officer* |
| Data object | Noun [state] | *Application [verified]* |
| Data store | Noun (system name) | *Customer DB* |
| Message flow | Message name (noun) | *Invoice* |

---

## 6. Pattern library — how to model standard situations

Most business-process control flow can be expressed with a small set of structured patterns. Each pattern corresponds to a soundness-preserving transformation per [[sources/1998-vanderaalst-verification-of-workflow-nets]] §5.

The mental model for reasoning about each pattern is [[concepts/token-semantics]]: every gateway has a defined token-flow rule (XOR routes one, AND spawns N, OR spawns k≤N), and patterns are correct iff their tokens balance.

#### Join-type selection heuristic ([[sources/2018-dumas-fundamentals-of-bpm-ch3-essential-process-modeling]] §3.2.3)

When a model fragment has multiple incoming branches and you're not sure which join type to use:

> **Start with XOR-join, next try AND-join, and if both lead to incorrect models use OR-join (which will work for sure).**

XOR is a passthrough (works for mutually-exclusive branches). AND synchronises (works for fully-parallel branches). OR is the most expressive but the most confusing — only fall back to it when the join must wait for an *unknown subset* of incoming branches.

### 6.1 Sequence

Two activities in order. The simplest pattern.

```
○──▶ A ──▶ B ──▶ ◎
```

**Rules**:
- One outgoing flow from A, one incoming to B.
- No gateway needed.

### 6.2 Exclusive choice (XOR split + merge)

One-of-N alternative paths.

```
                ┌──▶ A ──┐
○──▶ ◇? ──────┤        ├──▶ ◇──▶ ◎
                └──▶ B ──┘
```

**Rules**:
- XOR-split with conditions on outgoing flows (mutually exclusive + exhaustive).
- Always include a **default flow** (marked /) unless conditions are provably exhaustive.
- Matching XOR-merge consolidates flows — no synchronisation, just continuation.
- **Antipattern**: AND-merge after XOR-split → deadlock (the AND waits for all branches, but only one was taken).

### 6.3 Parallel split and join

All-of-N concurrent paths.

```
                ┌──▶ A ──┐
○──▶ ◇+ ──────┤        ├──▶ ◇+ ──▶ ◎
                └──▶ B ──┘
```

**Rules**:
- AND-split releases tokens to *all* outgoing branches simultaneously.
- AND-join *waits for* tokens on *all* incoming branches before proceeding.
- **Antipattern**: XOR-merge after AND-split → orphan tokens (each branch produces a token, the XOR fires once for the first arrival, leaving tokens stuck).

### 6.4 Structured loop

Repeat an activity while a condition holds.

Two valid forms:

**Pre-test (while loop)**:
```
○──▶ ◇? ──No──▶ ◎
       │ Yes
       ▼
       A
       │
       └──▶ ◇ (back to ◇?)
```

**Post-test (do-while loop)**:
```
○──▶ A ──▶ ◇? ──No──▶ ◎
                │ Yes
                └──▶ A (back to A)
```

**Rules**:
- Loop must have an exit condition that **eventually** evaluates true (livelock prevention).
- Activities inside the loop should be small (< 5 activities); larger loops should be sub-process candidates.
- BPMN provides a built-in loop marker (↺) on activities — equivalent to wrapping a single activity in a structured loop. Prefer the marker for single-activity loops.

### 6.5 Multi-instance

Repeat for each item in a collection (parallel or sequential).

- **Parallel multi-instance** (‖): all instances run concurrently. Use for "process each line item independently".
- **Sequential multi-instance** (≡): one after another. Use when order matters or shared resources prevent concurrency.

**Rules**:
- The collection must be specified (e.g., *"for each line item in order"*).
- Completion condition: typically *"all instances complete"* but can be *"first N complete"* for race-conditions.
- Use sub-process for non-trivial multi-instance bodies.

### 6.6 Event-based choice

Wait for the **first** of several possible events (race).

```
                  ✉ Message arrives ──▶ A
○──▶ ◇⬠ ─────┤
                  ⏰ Timeout         ──▶ B
```

**Rules**:
- Outgoing flows from event-based gateway must lead to **events** (not activities directly — events are the racers).
- Used heavily for response/timeout patterns: wait for customer reply OR 7-day timeout.

### 6.7 Boundary events (interrupting and non-interrupting)

Attach an event to an activity to handle interrupting conditions.

```
A ─── (timer 24h) ──▶ B  ← if timer fires during A, jump to B
```

**Rules**:
- **Interrupting** (solid boundary): cancels the activity, redirects to the boundary-event flow.
- **Non-interrupting** (dashed boundary): activity continues; a parallel branch starts at the boundary event.
- Common boundary events: timer (deadline), message (cancellation), error (failure), escalation.
- Boundary events are the canonical way to model exceptions — far cleaner than XOR-checking-every-step.

### 6.8 Compensation

Undo previously-completed work when later steps fail.

**Rules**:
- Activities that need undoing are marked compensable; each has a separate **compensation handler** (an activity attached via compensation association).
- A throw-compensation event triggers all relevant compensation handlers.
- Use sparingly — most processes don't need formal compensation; an exception flow that explicitly re-does the affected steps is often simpler.

### 6.9 Message exchange

Two pools communicating.

```
Pool A:  A1 ───▶ A2 ───▶ A3
                │           ▲
                ✉           ✉
                ▼           │
Pool B:  B1 ───▶ B2 ───▶ B3
```

**Rules**:
- Message flow (dashed) crosses pool boundary.
- Sender side: send task or throwing message event.
- Receiver side: receive task, catching message event, or message-typed start event.
- The **message itself** is named on the flow (e.g., *"Purchase Order"*) — not the activities sending/receiving it.

### 6.10 Decision-table-driven routing (DMN integration)

When a gateway condition is complex (multiple inputs, business rules), externalise to [[frameworks/dmn]]:

```
○──▶ [📋 Determine eligibility] ──▶ ◇? ──▶ ...
                  │
                  └─▶ DMN decision (Decision Requirements Diagram + Decision Table)
```

**Rules**:
- Use a **business rule task** to invoke the DMN decision.
- The decision returns an output; the gateway routes on that output.
- Don't put complex Boolean logic inside the gateway label — externalise it.

---

## 7. Quality criteria — concrete thresholds

These thresholds operationalise [[concepts/7pmg]] guidelines into measurable criteria. Use them as build-time targets.

### 7.1 Size criteria

| Metric | Target | Action if violated |
|---|---|---|
| Total elements (nodes + arcs) per view | ≤ 30 ideal · ≤ 50 hard limit | Decompose to sub-processes (G7) |
| Activities per view | ≤ 15 ideal · ≤ 25 hard limit | Identify candidate sub-processes |
| Lanes per pool | ≤ 7 | Split pool or aggregate roles |
| Pools per diagram | ≤ 4 | Use collapsed (black-box) pools for non-focal participants |

### 7.2 Connector criteria (G2)

| Metric | Target | Action if violated |
|---|---|---|
| Average connector degree | ≤ 3 | Refactor with intermediate gateways |
| Maximum connector degree | ≤ 4 | Split into nested gateways |
| OR-gateway count (G5) | 0 | Replace with XOR + explicit conditions |

**Connector degree** = (incoming + outgoing arcs). A 4-way XOR split has degree 5 (1 in + 4 out).

### 7.3 Structuredness criteria (G4)

| Metric | Target | Action if violated |
|---|---|---|
| Mismatched split-join pairs | 0 | Restructure |
| Implicit joins (task with multiple incoming flows) | 0 | Add explicit gateway |
| Unstructured loops (multiple entry/exit points) | 0 | Refactor as structured loop or sub-process |

### 7.4 Density criteria

| Metric | Target | Notes |
|---|---|---|
| Density = `|A| / (|N|·(|N|-1))` | ≤ 0.10 | Higher = more entangled, harder to read |
| Cyclomatic complexity = `|A| - |N| + 2` | ≤ 10 | McCabe-style; controls path count |

### 7.5 Label criteria (G6)

| Metric | Target | Action if violated |
|---|---|---|
| Verb-object activity labels | 100% | Rewrite |
| Label length | 8–40 chars typical · ≤ 60 hard | Split activity or shorten |
| State-based event labels | 100% | Rewrite |

### 7.6 Decomposition criteria (G7)

| Metric | Target | Action if violated |
|---|---|---|
| Top-level model elements | ≤ 50 | Extract single-entry-single-exit blocks as sub-processes |
| Sub-process nesting depth | ≤ 3 | Beyond 3 levels, navigation suffers |
| Sub-process internal size | ≤ 30 elements | Split further |

### 7.7 Layout criteria (empirical quality)

| Criterion | Target |
|---|---|
| Predominant flow direction | Left-to-right OR top-to-bottom (consistent within model) |
| Crossing arcs | ≤ 2 per view (eliminate via re-routing or sub-process extraction) |
| Element alignment | On grid; consistent spacing |
| Lane height proportional to content | Yes |
| Gateway-to-gateway distance | ≥ 1 element width |
| Font size consistent | Yes; legible at intended viewing size |

---

## 8. Decomposition strategy

Decomposition is the single most powerful quality lever — it shrinks visible complexity without losing detail.

### 8.1 When to decompose

Decompose when **any** of these hold:
- Total elements > 30 in a single view.
- A logical phase (e.g., "Validation", "Approval", "Settlement") has >5 internal activities.
- The same sub-flow appears in multiple processes (extract reusable sub-process).
- One lane has substantially more activity than others — the dense lane is a sub-process candidate.
- Multiple stakeholders have conflicting views of *one phase* — extract that phase as its own model.

### 8.2 What to decompose — single-entry-single-exit (SESE) regions

The cleanest decomposition extracts a region with:
- Exactly **one incoming sequence flow** (single entry).
- Exactly **one outgoing sequence flow** (single exit).
- All elements between entry and exit lie inside the region.

This guarantees the sub-process is a valid WF-net on its own (one start, one end — see [[concepts/workflow-net]]) and that replacement preserves overall behaviour.

### 8.3 Embedded vs reusable sub-processes

| Type | When to use |
|---|---|
| **Embedded sub-process** | Sub-flow is specific to this process; same lane assignments inherited; collapses cleanly |
| **Reusable sub-process (call activity)** | Sub-flow used in multiple processes; defines its own pool/lanes; versioned independently |

A sub-process invoked from one parent should be embedded; if reused, promote to call activity.

### 8.4 Naming hierarchical models

- Parent process: high-level verb-object (*"Handle insurance claim"*).
- Sub-process activity: verb-object describing what the sub-process does (*"Verify claim eligibility"*).
- The sub-process diagram itself: same name as the activity that calls it.
- Sub-sub-processes: more specific verb-object.

### 8.5 Anti-patterns in decomposition

- **One-activity sub-processes**: a sub-process with a single internal activity is just an activity — collapse.
- **Over-deep nesting**: depth > 3 makes navigation painful; consolidate.
- **Inconsistent boundaries**: a sub-process whose internal flow re-crosses the parent's lane structure → flatten.
- **Lazy sub-processing**: extracting a sub-process *purely* to hit the 50-element threshold without semantic coherence → re-think the boundary.

---

## 9. Data perspective — when and how to model

Data objects clarify what flows through the process. They are **always optional** for descriptive models but mandatory for executable ones.

### 9.1 When to model data

Include data objects when **any** holds:
- An activity's input requirements determine routing (XOR depends on data state).
- The same data item undergoes named state transitions (Application: submitted → verified → approved → archived).
- Compliance / auditability requires showing what data is processed.
- The model will become executable.

Skip data when:
- The model is for high-level documentation.
- Data flow is uncontroversial (every activity reads/writes the obvious item).

### 9.2 Data objects vs data stores

| Element | Persistence | Use for |
|---|---|---|
| **Data object** | Process-instance scope; lives only for the case | Documents, forms, in-flight items |
| **Data store** | Persistent across instances | Databases, file systems, customer registry |

### 9.3 Data associations

- **Input**: arrow from data object → activity (the activity consumes/reads).
- **Output**: arrow from activity → data object (the activity produces/writes).
- Bidirectional: separate input and output associations (don't use a single double-headed arrow).

### 9.4 Data states

Use bracketed states to track lifecycle: *"Application [draft]"* → *"Application [submitted]"* → *"Application [verified]"*. The same conceptual object appears multiple times with different states, connected to the activities that perform the transitions.

This is **far clearer** than using separate data objects (*"Draft application"*, *"Submitted application"*) which obscures the lifecycle.

---

## 10. Resource and organisational perspective

Pools and lanes are the dominant organisational construct in BPMN. Get them right.

### 10.1 Pool design

**One pool per participant**. A participant is:
- An **organisation** (your company; an external supplier).
- A **role at organisational level** (the central credit committee, when modelled abstractly).
- An **automated system** that owns process logic (the order management system, in some abstractions).

Choose pool granularity by **modelling goal**:
- For inter-organisational flows: pool per organisation.
- For intra-organisational flows: typically one pool with multiple lanes, plus collapsed pools for external parties.

### 10.2 Lane design

Lanes subdivide a pool. Choices:

- **Lane = role**: most common. *"Credit Officer"*, *"Account Manager"*, *"Customer Service Rep"*.
- **Lane = department / org unit**: when role granularity is too fine. *"Credit Department"*, *"Logistics"*.
- **Lane = system**: when the system performs activities autonomously (without a human). *"CRM System"*, *"Payment Gateway"*.

Don't mix levels — avoid one lane being a role (*"Credit Officer"*) and another being a department (*"Logistics"*) in the same pool.

### 10.3 Cross-lane handoffs

Every sequence flow crossing a lane boundary is a **handoff**. Each handoff is a quality risk:
- Possible information loss.
- Possible delay (queue at receiver).
- Possible accountability gap.

**Validate every handoff with both ends** — don't trust a single role's account of what they send/receive.

### 10.4 Black-box pools

For external participants whose internal process you don't model (and shouldn't), use **black-box pools** (collapsed): show only the pool boundary with message-flow connections. Don't model assumed internal activities — that's speculation.

### 10.5 Organisational anti-patterns

- **Lanes-as-systems mixed with lanes-as-roles**: confuses role from system.
- **One-task lanes**: a lane containing a single task — usually means the lane shouldn't exist; that task belongs in another lane.
- **Cross-pool sequence flows**: invalid; use message flows.
- **Pools-as-departments inside one organisation**: usually the wrong level. Departments are typically *lanes* in a single organisational pool.

---

## 11. Exception handling — the rainy-day requirement

[[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]] §5.2.2 emphasises rainy-day path coverage. The model must reflect what can go wrong, not just what goes right.

### 11.1 The exception taxonomy

For each activity, ask the following four questions (Dumas exception taxonomy):

1. **Internal business exception** — can the business state make this activity impossible? (Out-of-stock, ineligible application, insufficient funds.)
2. **External business exception** — can an external party cancel or change course? (Customer cancels, supplier defaults, regulator intervenes.)
3. **Internal technology exception** — can the supporting IT system fail? (Database unavailable, downstream service down.)
4. **Activity timeout** — is there an implicit or explicit deadline? What happens when it's missed?

Each "yes" answer yields a candidate boundary event or alternative path.

### 11.2 Exception modelling patterns

| Pattern | Use for |
|---|---|
| **Boundary timer event** (interrupting) | Activity timeout — cancel and proceed to escalation |
| **Boundary message event** | External cancellation — stop activity, take cancel path |
| **Boundary error event** | Internal failure — handle locally |
| **Boundary escalation event** | Hand off to higher authority without aborting |
| **Boundary signal event** | React to broadcast across multiple processes |
| **Event sub-process (interrupting)** | Cleanup logic for terminating exceptions (compliance log, rollback) |
| **Event sub-process (non-interrupting)** | Side-channel reactions that don't stop main flow (notify management) |

### 11.3 Exception modelling rules

- Boundary events attach to **activities only** (not gateways, events, or pools).
- Interrupting boundary events **cancel** the activity; non-interrupting **don't**.
- Always model the **happy path first** — add exception flows only after the main path is stable.
- Each exception flow must terminate (lead to an end event, possibly a typed-error end event).

### 11.4 The "what about exceptions?" reflex

Per Dumas, the most common discovery failure is the **sunny-day-only model**. Counter-mechanism: at every activity in the model, run the four exception questions. Each unmodelled exception is either:
1. A real risk to model (add boundary event), or
2. A documented "we accept this can happen and have no formal handling" (add annotation), or
3. A rainy-day path that's truly out of scope (annotate the scope decision).

Silently omitting exceptions is the failure mode.

---

## 12. Multi-perspective integration — when BPMN is not enough

BPMN is the operational control-flow notation. It is *not* the right tool for every modelling job.

### 12.1 BPMN + DMN

Use [[frameworks/dmn]] when:
- Decision logic involves multiple input variables.
- Decision logic changes more frequently than the process flow.
- Business analysts need to maintain decision rules independently of the process model.
- Multiple processes use the same decision logic.

Pattern: BPMN business rule task → DMN decision → output drives BPMN gateway.

Don't bake complex decision tables into XOR gateway labels. They become unmaintainable.

### 12.2 BPMN + CMMN

Consider [[frameworks/cmmn]] when:
- Activity order is largely **knowledge-worker driven** rather than predefined.
- Many activities are optional / conditional with no fixed sequence.
- The process is **case-centric** (one case = one customer file with discretionary handling).

CMMN is a separate notation; sub-cases can be invoked from BPMN.

### 12.3 BPMN + DECLARE (declarative)

Consider [[frameworks/declare]] when:
- Constraints (compliance rules) matter more than flow.
- Knowledge-intensive process with many valid orderings.
- Loosely-structured process where imperative control flow forces frequent deviations.

DECLARE expresses constraints (e.g., *"X must occur before Y"*) using LTL templates rather than directed graphs. Combined approaches use BPMN for the structured backbone and DECLARE for compliance constraints over it.

### 12.4 When BPMN is wrong

- **Strategy / capability maps** — use ArchiMate or capability matrices.
- **Pure data flow** — use UML class/sequence diagrams.
- **Customer journey** — use journey maps; BPMN's process-centric framing misses the customer's experience.
- **High-level value chain** — use Porter's value chain or APQC PCF.

Don't force BPMN onto problems it wasn't designed for. The 7PMG paper's empirical foundation is on control-flow understandability — outside that domain, the guidelines don't apply.

---

## 13. Validation workflow — gates from draft to sign-off

A model passes through validation gates. Each gate has a clear pass/fail criterion.

### 13.1 Gate 1 — Self-review (analyst alone)

Before showing to anyone:

- [ ] Single start, single end (or distinct named end events per outcome).
- [ ] All activities verb-object labelled.
- [ ] All gateways correctly typed and balanced.
- [ ] All lanes assigned; no orphan activities.
- [ ] Layout: predominant direction consistent; ≤ 2 crossing arcs.
- [ ] Soundness sanity-check: walk through the diagram and confirm every reachable state can complete.

### 13.2 Gate 2 — Tool-based validation

Run the modelling tool's validator:

- [ ] Notation-syntactic errors: 0.
- [ ] If supported: soundness/structural checks pass.
- [ ] BPMN 2.0 XML exports cleanly.

Use [[concepts/process-model-complexity-metrics]] to compute size, density, max-degree, mismatch — fail if any threshold from §7 is violated.

### 13.3 Gate 3 — Domain-expert validation

Per [[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]] §5.4.2 + [[sources/2012-ottensooser-graphical-vs-textual]]:

- [ ] **Translate model to natural language** (or write a structured use case) — present this *first*.
- [ ] Walk the expert through the natural-language version.
- [ ] Show BPMN as supplement *after*.
- [ ] Capture every falsification verbatim.
- [ ] Probe completeness with the four exception-taxonomy questions per activity.
- [ ] **Cross-validate every cross-lane handoff** with the receiving role separately.

Expect ≥ 2 iterations. Mark model uncertainties (annotation, colour) so the next iteration has targets.

### 13.4 Gate 4 — Process-owner sign-off

The process owner closes semantic + organisational quality. They sign off when:

- [ ] All identified errors from Gate 3 resolved.
- [ ] Modelling goal (§1.4) is met.
- [ ] Annotated decisions about scope, granularity, and disagreements are explicit.
- [ ] Versioned in the process repository.

Without process-owner sign-off, the model is **not** the as-is process — it's the analyst's draft.

### 13.5 Gate 5 — Audience-fit check

Before publishing to broader stakeholders:

- [ ] Identify the audience type (domain expert, business analyst, novice, executive).
- [ ] For non-experts: pair the BPMN with a structured **written use case** or natural-language description (Ottensooser: comprehension lift only when text precedes BPMN).
- [ ] Verify that the audience can read and react to the model — not just acknowledge it.

---

## 14. Governance and lifecycle

A model is a long-lived artefact. Plan for change.

### 14.1 Versioning

- Use semantic versioning: MAJOR.MINOR.PATCH (1.2.0).
- MAJOR change: structural redesign (new lanes, restructured flow).
- MINOR: new exception paths, refined labels, corrections.
- PATCH: typos, layout fixes.

### 14.2 Repository structure

A typical process repository has:

```
processes/
  <process-name>/
    current/
      <process-name>.bpmn          (BPMN 2.0 XML)
      <process-name>.dmn           (decision logic if any)
      <process-name>.png            (rendered)
      <process-name>-use-case.md    (companion natural-language)
      README.md                     (scope, owner, last-validated date)
    history/
      v1.0.0/...
      v1.1.0/...
```

Version history is critical for compliance / audit traceability.

### 14.3 Annotations as metadata

Use BPMN annotations to record:
- **Scope decisions**: *"Out of scope: international shipping (covered by separate model)"*.
- **Disagreements parked**: *"Sales says 24h; Support says 48h — pending policy clarification 2026-Q3"*.
- **Frequency / volume**: *"This branch ~5% of cases per 2026 logs"*.
- **Performance targets**: *"SLA: 4 business hours"*.
- **Source links**: *"See policy PR-2024-08, §3.2"*.

Annotations carry the *story* of the model — its provenance, its uncertainties, its governance. A stripped-clean diagram loses all of that.

### 14.4 Linking to runtime

For models that drive execution:
- BPMN element IDs map to workflow-engine task IDs (Camunda, Activiti, Flowable, etc.).
- Event log events should carry the BPMN element ID — enables conformance checking ([[concepts/conformance-checking]]) against the model.
- Data objects map to process-variables in the engine.

This bidirectional link is what makes process mining (post-hoc conformance) useful.

### 14.5 Maintenance triggers

Re-validate the model when **any** holds:
- Conformance check shows fitness < 0.85 against current event log.
- A new regulation or policy changes process logic.
- Organisational restructuring changes lanes/pools.
- Annual re-review (every model gets at least an annual touch).

---

## 15. Anti-patterns — top 20 builder mistakes

Consolidating Dumas §5.4, [[sources/2010-mendling-reijers-vanderaalst-7pmg]], [[sources/1998-vanderaalst-verification-of-workflow-nets]], and the prior synthesis:

1. **Multiple start events** — one per interview "trigger". Violates G3. Fix: one start + XOR.
2. **Multiple end events for the same outcome** — violates G3 spirit. Fix: one end event per outcome.
3. **Implicit join** — multiple sequence flows entering a task without a gateway. Fix: explicit XOR-merge or AND-join.
4. **Mismatched split-join types** — AND-split + XOR-join (orphan tokens) or XOR-split + AND-join (deadlock). Fix: match types.
5. **OR-gateway without explicit semantics** — analyst hedging. Fix: convert to XOR + explicit conditions; rare cases keep OR with annotation.
6. **Loop without exit condition** — livelock. Fix: explicit exit condition.
7. **Activity at micro-step level** — *"Click Submit button"*, *"Open file"*. Violates discovery discipline. Fix: lift to activity granularity.
8. **Activity at process-level granularity** — *"Order management"* as a single activity. Fix: decompose to sub-process or activities.
9. **Long noun-phrase labels** — *"Complaint analysis and dispatch"*. Violates G6. Fix: rewrite verb-object.
10. **Compound activities** — *"Verify and approve and notify"*. Fix: split into three activities.
11. **Connector with degree 6+** — too many branches. Fix: split into nested gateways.
12. **Single-activity sub-process** — sub-process containing one task. Fix: collapse to plain activity.
13. **Cross-pool sequence flow** — invalid. Fix: message flow.
14. **Pools-as-departments within one organisation** — wrong level. Fix: lanes within one pool.
15. **Black-box pools modelled as if inspectable** — speculating internal flow of external party. Fix: collapse to message-only interface.
16. **Sunny-day-only model** — no rainy-day paths. Fix: apply exception taxonomy per activity.
17. **Hidden upstream dependencies** — activity shown as triggered by event X but actually requires X+Y. Fix: explicit AND-join.
18. **Showing raw BPMN to domain expert for validation** — empirically counterproductive ([[sources/2012-ottensooser-graphical-vs-textual]]). Fix: pair with natural-language description.
19. **Treating every complaint as a structural variant** — frequency-blind. Fix: ask frequency questions; separate sporadic anecdote from structural variant.
20. **Modelling during the first interview** — diminished listening + premature commitment. Fix: model offline between interviews.

---

## 16. Modelling-goal × pattern matrix — quick decision aid

| If your goal is... | Emphasise... | De-emphasise... |
|---|---|---|
| Documentation | Verb-object labels, lane assignment, rainy-day paths, layout | Data objects, executable types, performance annotations |
| Compliance evidence | Boundary events for every exception, message flows, data objects, sign-off annotations | Visual minimalism (audit needs explicitness) |
| Redesign baseline | Bottlenecks visible, frequency annotations, value-added vs waste markings | Executable detail (premature) |
| Simulation | Sound model, branch probabilities, durations, resource pools | Free-text annotations (simulator can't read them) |
| Executable workflow | Type markers on tasks, data mappings, error events, DMN-linked rules | Free-text annotations only relevant to humans |
| Training material | Few elements per view, large icons, narrative companion | Detailed exceptions, rare paths |

---

## 17. Quick-reference checklist (1-page)

```
PRE-MODELLING
□ TRAC scope defined (Trigger, Result, ~5 Activities, Cases)
□ Stakeholder roster (customer, every participant role, owner)
□ Source material gathered (interviews, documents, observation)
□ Modelling goal stated: [doc/compliance/redesign/sim/exec/training]
□ BPMN 2.0 tool selected

STRUCTURAL (mandatory)
□ Single start event
□ Single end event (or one per distinct outcome)
□ No dangling elements (everything reachable from start)
□ All sequence flows within pools
□ All message flows cross pools
□ All splits have matching joins of same type
□ All tasks have one in/one out (or use gateway)
□ All boundary events on activities (not on events/gateways)

LABELS
□ Activities: verb-object, active, ≤ 60 chars
□ Events: state/past-participle (e.g., "Order received")
□ XOR gateways: question, branches labelled with answers
□ AND gateways: unlabelled
□ Lanes: role/system/department (consistent level)
□ Pools: participant name
□ Data objects: noun [state]

QUALITY THRESHOLDS (7PMG)
□ Total elements per view ≤ 30 ideal, ≤ 50 hard
□ Max connector degree ≤ 4
□ Avg connector degree ≤ 3
□ OR-gateway count = 0
□ Mismatch count = 0
□ Density ≤ 0.10
□ Verb-object labels = 100%

EXCEPTIONS (rainy-day discipline)
For each activity, ask:
□ Internal business exception possible? → boundary event
□ External business exception possible? → boundary event
□ Internal technology exception possible? → boundary event
□ Timeout? → boundary timer event

VALIDATION GATES
□ Gate 1 — self-review checklist
□ Gate 2 — tool validator passes; metrics within thresholds
□ Gate 3 — domain-expert NL walkthrough; ≥ 2 iterations
□ Gate 4 — process-owner sign-off
□ Gate 5 — audience-fit check (pair with use case for non-experts)

GOVERNANCE
□ Versioned in repository
□ Annotations capture scope decisions, frequencies, sources
□ Companion natural-language use case authored
□ BPMN 2.0 XML exported
```

---

## 18. Acknowledged gaps (next ingest candidates)

This guide rests on the same primary sources as [[syntheses/process-model-quality-and-soundness-evaluation-guide]]; closing those sources' gaps tightens this guide too. Specific to the *building* (vs evaluating) angle:

- **OMG BPMN 2.0 specification** — the canonical reference for notation rules. Not yet ingested as a source page.
- **Dumas Fundamentals Ch. 3 (Essential Process Modeling)** and **Ch. 4 (Advanced Process Modeling)** — currently summarised in the meta source page but not deep-dived. Would supply detailed BPMN element semantics directly.
- **Mendling 2008** *Metrics for Process Models* — empirical complexity-metrics calibration.
- **Reijers & Mendling 2008** *Modularity in Process Models* — empirical foundation for §8 decomposition thresholds.
- **Silver 2011** *BPMN Method and Style* — practitioner-oriented BPMN style guide; would add concrete naming/layout examples.
- **Object Management Group BPMN sample model collection** — for canonical pattern examples.
- **Allweyer 2010** *BPMN 2.0: Introduction to the Standard* — accessible, comprehensive notation reference.
- **Rosemann's 22 modelling pitfalls** — referenced from [[syntheses/interview-structuring-for-process-models]] §5.

When these are ingested, this guide can be upgraded delta-by-delta — particularly §2 (richer element catalogue with formal semantics), §6 (more pattern variants), §11 (broader exception-handling techniques).

---

## 19. How this guide relates to the others

Three sister documents form a discovery → modelling → evaluation chain:

```
┌──────────────────────────────────────┐
│ INTERVIEW STRUCTURING                │  How to elicit the raw material
│ (interview-structuring-for-process-  │  • Stakeholder analysis
│  models)                             │  • Hypothesis pack
│                                      │  • Sunny + rainy-day balance
└──────────┬───────────────────────────┘
           │ produces interview notes
           ▼
┌──────────────────────────────────────┐
│ BPMN MODELLING PRACTICAL GUIDE       │  How to BUILD the model    ← this document
│ (this document)                      │  • Element catalogue
│                                      │  • Naming conventions
│                                      │  • Pattern library
│                                      │  • Quality thresholds
│                                      │  • Validation gates
└──────────┬───────────────────────────┘
           │ produces BPMN model
           ▼
┌──────────────────────────────────────┐
│ EVALUATION GUIDE                     │  How to ASSESS the model
│ (process-model-quality-and-          │  • Five-layer rubric
│  soundness-evaluation-guide)         │  • LLM-assisted review prompt
│                                      │  • Pass/fail verdict
└──────────────────────────────────────┘
```

Use this practical guide *during* construction. Use the evaluation guide *after* construction (and during peer review). Use the interview structuring synthesis *before* construction.

---

## Sources & related

**Primary**: [[sources/2018-dumas-fundamentals-of-bpm]] (§3, §4, §5) · [[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]] · [[sources/2010-mendling-reijers-vanderaalst-7pmg]] · [[sources/1998-vanderaalst-verification-of-workflow-nets]] · [[sources/2006-krogstie-sindre-jorgensen-revised-sequal-framework]] · [[sources/2012-ottensooser-graphical-vs-textual]]

**Concepts**: [[concepts/process-model-quality]] · [[concepts/soundness]] · [[concepts/workflow-net]] · [[concepts/7pmg]] · [[concepts/sequal-framework]] · [[concepts/process-model-complexity-metrics]] · [[concepts/conformance-checking]]

**Frameworks**: [[frameworks/bpmn]] · [[frameworks/dmn]] · [[frameworks/cmmn]] · [[frameworks/declare]]

**Sister syntheses**: [[syntheses/interview-structuring-for-process-models]] (upstream) · [[syntheses/process-model-quality-and-soundness-evaluation-guide]] (downstream) · [[syntheses/discovery-method-session-templates]] · [[syntheses/qualitative-discovery-method-selection-matrix]]

**Methods**: [[methods/process-discovery-methods]] · [[methods/process-mining-basics]]