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:

Option to complete — every reachable state can reach the end event.
Proper completion — when end event fires, no orphan tokens remain (Dumas's BPMN-specific formulation: each token must reach a different end event).
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.

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 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 ──▶ ◎
○──▶ 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 ──┘
                ┌──▶ 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 ──┘
                ┌──▶ 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 ◇?)
○──▶ ◇? ──No──▶ ◎
       │ Yes
       ▼
       A
       │
       └──▶ ◇ (back to ◇?)

Post-test (do-while loop):

○──▶ A ──▶ ◇? ──No──▶ ◎
                │ Yes
                └──▶ A (back to A)
○──▶ 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
                  ✉ 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
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
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)
○──▶ [📋 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	/ (
Cyclomatic complexity = `	A	-

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):

Internal business exception — can the business state make this activity impossible? (Out-of-stock, ineligible application, insufficient funds.)
External business exception — can an external party cancel or change course? (Customer cancels, supplier defaults, regulator intervenes.)
Internal technology exception — can the supporting IT system fail? (Database unavailable, downstream service down.)
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:

A real risk to model (add boundary event), or
A documented "we accept this can happen and have no formal handling" (add annotation), or
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/
  &#x3C;process-name>/
    current/
      &#x3C;process-name>.bpmn          (BPMN 2.0 XML)
      &#x3C;process-name>.dmn           (decision logic if any)
      &#x3C;process-name>.png            (rendered)
      &#x3C;process-name>-use-case.md    (companion natural-language)
      README.md                     (scope, owner, last-validated date)
    history/
      v1.0.0/...
      v1.1.0/...
processes/
  &#x3C;process-name>/
    current/
      &#x3C;process-name>.bpmn          (BPMN 2.0 XML)
      &#x3C;process-name>.dmn           (decision logic if any)
      &#x3C;process-name>.png            (rendered)
      &#x3C;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:

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

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