BPMN Elements Reference

import { Tabs, TabItem } from ‘@astrojs/starlight/components’;

BPMN basics

Business Process Model and Notation (BPMN) is an international standard for creating process diagrams that are both human-readable and technically precise. This reference guide covers all BPMN elements available in Klarify and explains when and how to use each one effectively.

Understanding BPMN notation

BPMN uses specific shapes and symbols to represent different aspects of business processes:

Circles represent events (things that happen)
Rectangles represent activities (work that is done)
Diamonds represent gateways (decisions and parallel flows)
Arrows represent sequence flows (the order of activities)

Each shape can have different variations and decorations to convey specific meaning, making BPMN diagrams both precise and universally understood.

Element categories overview

Flow Objects - The main graphical elements:

Events (start, intermediate, end)
Activities (tasks, sub-processes)
Gateways (decision points, parallel splits)

Connecting Objects - Lines that connect flow objects:

Sequence flows (normal process flow)
Message flows (communication between processes)
Associations (additional information connections)

Artifacts - Additional information elements:

Data objects (information used or produced)
Text annotations (explanatory notes)
Groups (visual grouping without semantic meaning)

Swimlanes - Organizational containers:

Pools (different organizations or systems)
Lanes (roles within the same organization)

Events

Events represent things that happen during the course of a business process. They have a cause (trigger) or an impact (result) and are generally represented by circles.

Start events (None, Message, Timer, etc.)

None Start Event (Simple Circle):

Use when: The process starts without a specific trigger
Example: “Begin daily operations,” “Start monthly review”
Best practice: Use for processes that start on schedule or by human decision

Message Start Event (Envelope Icon):

Use when: The process starts when a message or communication is received
Example: “Customer submits support request,” “Vendor sends invoice”
Best practice: Specify what type of message triggers the process

Timer Start Event (Clock Icon):

Use when: The process starts at a specific time or interval
Example: “Monthly report generation,” “Weekly team meeting”
Best practice: Include timing details in the element description

Signal Start Event (Triangle Icon):

Use when: The process starts in response to a signal from another process
Example: “Begin shipping when order is confirmed,” “Start review when document is submitted”
Best practice: Name the signal clearly to avoid confusion

End events (None, Message, Error, etc.)

None End Event (Thick Circle):

Use when: The process ends normally without producing a specific result
Example: “Process completed,” “Task finished”
Best practice: Use for straightforward process completion

Message End Event (Envelope Icon with Thick Border):

Use when: The process ends by sending a message or communication
Example: “Send confirmation email,” “Notify customer of completion”
Best practice: Specify what message is sent and to whom

Error End Event (Lightning Bolt Icon):

Use when: The process ends abnormally due to an error condition
Example: “Payment failed,” “Approval rejected”
Best practice: Clearly describe the error condition for troubleshooting

Terminate End Event (Full Black Circle):

Use when: The process ends immediately, terminating all active flows
Example: “Emergency stop,” “Critical error abort”
Best practice: Use sparingly, only for situations requiring immediate process termination

Intermediate events (Boundary, Catching, Throwing)

Intermediate Catching Events (Double Circle):

Purpose: Pause process flow until a specific event occurs
Common types: Timer (wait for time), Message (wait for communication), Signal (wait for signal)
Example: “Wait for approval,” “Pause until payment received”

Intermediate Throwing Events (Double Circle with Filled Icon):

Purpose: Generate events during process execution
Common types: Message (send communication), Signal (trigger other processes)
Example: “Send status update,” “Trigger backup process”

Boundary Events (Attached to Activities):

Purpose: Handle exceptions or alternative paths during activity execution
Interrupting: Stops the activity when triggered
Non-interrupting: Continues the activity while handling the event
Example: Timer boundary for “If approval takes more than 2 days,” Error boundary for “If system unavailable”

Activities

Activities represent work that is performed within a business process. They are depicted as rectangles and can range from simple tasks to complex sub-processes.

Tasks (User, Service, Manual, etc.)

User Task (Person Icon):

Use when: A human performs the work using a software application
Example: “Review customer application,” “Update project status”
Best practice: Specify who performs the task and what system they use

Service Task (Gear Icon):

Use when: An automated system performs the work
Example: “Generate report,” “Send automated email”
Best practice: Name the specific service or system involved

Manual Task (Hand Icon):

Use when: A human performs physical work without software
Example: “Package product,” “File physical documents”
Best practice: Describe the physical action required

Script Task (Script Icon):

Use when: Automated script or code execution is required
Example: “Calculate totals,” “Validate data format”
Best practice: Indicate the type of script or calculation performed

Send Task (Filled Envelope):

Use when: The task involves sending a message
Example: “Email confirmation,” “SMS notification”
Best practice: Specify the communication method and recipient

Receive Task (Empty Envelope):

Use when: The task involves receiving a message
Example: “Receive payment confirmation,” “Get approval response”
Best practice: Specify what is received and from whom

Sub-processes and Call activities

Sub-Process (Rectangle with Plus Sign):

Use when: A task is complex enough to warrant its own detailed process model
Collapsed view: Shows only the high-level activity
Expanded view: Shows the detailed process within
Example: “Customer Onboarding” containing multiple detailed steps

Call Activity (Thick Border Rectangle):

Use when: You want to reference another process model
Reusability: The same process can be called from multiple places
Maintenance: Changes to the called process affect all references
Example: “Approve Request” that references a standard approval process

Activity markers and properties

Loop Marker (Circular Arrow):

Standard Loop: Repeat until condition is met
Multi-Instance: Perform for each item in a collection
Example: “Review each item” or “Repeat until approved”

Compensation Marker (Reverse Arrow):

Use when: Activity can be “undone” if needed
Example: “Reserve inventory” with compensation “Release inventory”

Ad Hoc Marker (Squiggly Line):

Use when: Activities can be performed in any order
Example: “Gather requirements” where different information can be collected in any sequence

Gateways

Gateways control how sequence flows interact - they can split a single flow into multiple flows or merge multiple flows into one.

Exclusive (XOR) gateways

Symbol: Diamond with X or no symbol Decision logic: Only one outgoing path can be taken

Perfect for:

Yes/No decisions
Mutually exclusive choices
Single-criterion decisions

Examples:

“Is amount over $1000?” → Yes or No
“Customer type?” → Individual, Business, or Government
“Payment method?” → Credit Card, Cash, or Check

Labeling flows:

Use clear conditions: “Amount > $1000” not “High amount”
Include else conditions: “All other amounts” for clarity
Avoid overlapping conditions

Gateway naming:

Use question format: “Is customer verified?”
Be specific: “Credit score > 650?” not “Good credit?”
Include decision criteria in gateway description

Parallel (AND) gateways

Symbol: Diamond with plus sign (+) Execution logic: All outgoing paths are taken simultaneously

Parallel Split:

Creates multiple concurrent flows
All paths start at the same time
No conditions required on outgoing flows

Parallel Join:

Waits for all incoming flows to complete
Process continues only when all paths are finished
Synchronizes parallel work

Example scenario:

Order Processing → Parallel Split
                 ├─ Inventory Check
                 ├─ Credit Verification
                 └─ Shipping Calculation
                 → Parallel Join → Confirm Order

Inclusive (OR) gateways

Symbol: Diamond with circle (O) Decision logic: One or more outgoing paths can be taken

Use when:

Multiple conditions can be true simultaneously
Optional parallel activities
Complex decision scenarios

Example: “Customer preferences” gateway might trigger:

Email notifications (if customer wants email)
SMS alerts (if customer wants SMS)
Phone call (if priority customer)

Inclusive Join:

Waits only for active paths from the corresponding split
More complex than parallel join
Useful for optional parallel work

Event-based gateways

Symbol: Diamond with pentagon or circle Decision logic: First event to occur determines path taken

Exclusive Event Gateway:

Only one of several possible events can happen
First event to occur determines which path is followed
Other events are ignored

Parallel Event Gateway:

Multiple events must occur (similar to parallel gateway)
All expected events must happen before proceeding

Example:

Submit Request → Event Gateway
                ├─ Email Response
                ├─ Phone Call
                └─ Web Portal Update

Whichever response method the customer uses first determines the flow.

Flow objects

Flow objects connect the main process elements and define the sequence and conditions of process execution.

Sequence flows

Standard Sequence Flow (Solid Arrow):

Purpose: Shows normal flow of the process
Usage: Connect activities, events, and gateways in order
Conditions: Can include conditions when used after gateways

Default Sequence Flow (Slash Marked Arrow):

Purpose: Default path when no other conditions are met
Usage: One default flow per exclusive gateway
Best practice: Label as “Otherwise” or “Default”

Conditional Sequence Flow (Diamond Start Arrow):

Purpose: Flow taken only when specific conditions are met
Usage: Outgoing flows from exclusive gateways
Best practice: Clearly label the condition

Message flows

Symbol: Dashed line with open arrow and envelope Purpose: Show communication between different participants

Between Pools:

Message flows can only connect different pools
Represent communication between organizations
Show information exchange, not control flow

Types of Messages:

Request messages: Asking for information or action
Response messages: Providing requested information
Notification messages: Informing about status or events

Example: Customer pool sends “Order Request” message to Company pool Company pool sends “Order Confirmation” message back to Customer pool

Association flows

Symbol: Dotted line with open arrow Purpose: Connect artifacts to flow objects for additional information

Common uses:

Connect data objects to activities that use them
Link text annotations to relevant process elements
Associate groups with contained elements

Direction:

Directed association: Shows direction of relationship
Non-directed association: Shows general relationship without direction

Artifacts

Artifacts provide additional information about the process without affecting the flow logic.

Data objects and stores

Data Object (Document Icon):

Purpose: Represent information created, manipulated, or used by activities
States: Can show different states of the same data (Draft, Approved, etc.)
Example: “Customer Order,” “Invoice,” “Report”

Data Input (Document with Arrow In):

Purpose: Data required by an activity to execute
Example: “Customer Requirements” needed for “Design Product”

Data Output (Document with Arrow Out):

Purpose: Data produced by an activity
Example: “Test Results” produced by “Run Quality Tests”

Data Store (Cylinder with Lines):

Purpose: Persistent data storage (database, file, etc.)
Example: “Customer Database,” “Inventory System,” “Document Archive”

Text annotations

Symbol: Square bracket with text Purpose: Provide additional explanatory information

Effective use:

Clarify complex conditions on gateway flows
Explain business rules that affect activities
Provide examples of typical inputs or outputs
Reference external documentation like policies or procedures

Best practices:

Keep annotations concise but informative
Use annotations to explain “why” not just “what”
Position annotations near relevant elements
Don’t overuse - too many annotations clutter the diagram

Groups

Symbol: Dashed rectangle around elements Purpose: Visual grouping without semantic meaning

When to use groups:

Logical phases of a process (Planning, Execution, Review)
Departmental responsibility areas
Related activities that form a conceptual unit
Documentation purposes for process explanation

Important: Groups don’t affect process flow - they’re purely visual aids

Swimlanes

Swimlanes organize process elements by responsibility, showing who does what in cross-functional processes.

Pools and lanes

Pool (Large Container):

Purpose: Represent different organizations or major business entities
Usage: Customer pool, Vendor pool, Internal pool
Message flows: Required for communication between pools

Lane (Subdivision of Pool):

Purpose: Represent roles, departments, or systems within an organization
Usage: Sales lane, Operations lane, Manager lane
Sequence flows: Can cross lane boundaries within the same pool

Cross-functional processes

Design principles:

Clear responsibility: Each activity clearly assigned to appropriate lane
Logical flow: Process flows logically between responsible parties
Minimal handoffs: Reduce unnecessary transfers between lanes
Clear communication: Message flows show inter-pool communication

Example structure:

Customer Pool
├─ Customer Lane

Company Pool
├─ Sales Lane
├─ Operations Lane
└─ Finance Lane

Best practices:

Start simple: Begin with major roles, add detail as needed
Consistent width: Keep lanes roughly the same width for clean appearance
Logical order: Arrange lanes in logical sequence (often matching organizational hierarchy)
Clear labels: Use role names that are immediately recognizable

Ready to apply these BPMN elements in practice? See our Process Modeling Tutorial for step-by-step guidance on creating effective process diagrams using these elements.