PlantUML BPMN Diagram Syntax Guide

What is a BPMN Diagram?

A Business Process Model and Notation (BPMN) Diagram is a behavioral blueprint used to visualize business processes, workflows, and operational steps across different roles or services. Rather than building raw BPMN 2.0 XML or manually aligning visual elements on a drag-and-drop canvas, VPasCode lets you write BPMN process flows using a simple, human-friendly PlantUML activity diagram syntax. With VPasCode, you can instantly turn text definitions into standardized BPMN business process diagrams. This guide covers the essential syntax elements you need to build clear, publication-ready process flows.

Core Syntax Guide: Elements and Constructs

Building a BPMN diagram in VPasCode relies on PlantUML activity diagram constructs wrapped inside @startuml and @enduml tags, enhanced with explicit BPMN stereotypes and parent-child partition names.

1. Modeling Pools and Swimlanes

To define organizational responsibility, use partition bars (|...|). VPasCode uses a colon separator (Parent:Child) to represent nested pools and swimlanes:
|E-Commerce Platform|
:<<UserTask>> Receive Order;

|Warehouse:Fulfillment|
:<<ManualTask>> Pick & Pack Items;

|Logistics:Delivery|
:<<ServiceTask>> Assign Courier;

Pro Tip: Using |Pool:Lane| keeps your diagram readable by grouping internal departments (like Intake, Assessment, or Payout) cleanly inside an overall organizational pool (like Claims).

2. Defining Explicit BPMN Task Types

Rather than generic action boxes, you can declare the exact nature of an activity by adding a BPMN task stereotype before the task label:
:<<UserTask>> Submit Claim;
:<<ServiceTask>> Validate Policy Coverage;
:<<ScriptTask>> Calculate Payout Amount;
:<<BusinessRuleTask>> Auto-Approve Claim;
:<<ManualTask>> Perform Field Investigation;
:<<SendTask>> Send Acknowledgement;
:<<ReceiveTask>> Receive Payment Confirmation;

Supported Task Types:

  • <<UserTask>>: Work completed by a human user through an application interface.
  • <<ServiceTask>>: Automated work performed by an internal or third-party service.
  • <<ManualTask>>: Physical work executed without system involvement.
  • <<ScriptTask>>: Automated work executed by an internal software engine script.
  • <<BusinessRuleTask>>: Automated decision processing based on defined business logic.
  • <<SendTask>>: An outbound message or notification sent to an external participant.
  • <<ReceiveTask>>: An inbound message or payload received from an external participant.

3. Representing Gateways and Decision Logic

Model decision points, conditional branches, and workflow splits using familiar PlantUML if, then, else, and endif statements:
if (Requires Adjuster Review?) then (yes)
  :<<UserTask>> Assign Adjuster;
  :<<ManualTask>> Perform Field Investigation;
else (no)
  :<<BusinessRuleTask>> Auto-Approve Claim;
endif

VPasCode automatically maps decision logic into standard BPMN gateway symbols (such as Exclusive, Parallel, or Inclusive gateways) depending on the branching structure.

4. Process Boundaries: Start and Stop Events

Mark the entry and exit points of your process using standard start and stop keywords. These render cleanly as BPMN Start and End events:
start
:<<UserTask>> Submit Form;
:<<ServiceTask>> Process Request;
stop


Best Practices for Clean Layouts

  • Use Action-Oriented Labels: Always start task descriptions with a strong verb (e.g., <<ServiceTask>> Validate Policy Coverage).
  • Set Max Element Widths: Add custom style directives at the top of your script (e.g., MaximumWidth 160) to prevent long text labels from causing excessive horizontal stretch.
  • Group Lanes under Parent Pools: Keep swimlanes organized logically using the |Pool:Lane| syntax to avoid cluttering the visual canvas.

Real-World PlantUML BPMN Diagram Examples

Copy and paste these blueprints directly into your VPasCode editor panel to see them render in real time.

Example 1: Core Insurance Claim Processing

This blueprint models an insurance claim workflow spanning a Policyholder and multiple internal departments within a Claims pool.
@startuml
title Insurance Claim Process BPD

<style>
element {
  MaximumWidth 160
}
</style>

|Policyholder|
start
:<<UserTask>> Submit Claim;
:<<UserTask>> Upload Supporting Documents;

|Claims:Intake|
:<<ServiceTask>> Validate Policy Coverage;
:<<SendTask>> Send Acknowledgement to Policyholder;

|Claims:Assessment|
:<<UserTask>> Assess Claim Details;
:<<ScriptTask>> Calculate Payout Amount;
if (Requires Adjuster Review?) then (yes)
  :<<UserTask>> Assign Adjuster;
  :<<ManualTask>> Perform Field Investigation;
else (no)
  :<<BusinessRuleTask>> Auto-Approve Claim;
endif
:<<UserTask>> Approve Final Decision;

|Claims:Payout|
if (Claim Approved?) then (yes)
  :<<ServiceTask>> Schedule Payment;
  :<<ReceiveTask>> Receive Payment Confirmation;
else (no)
  :<<SendTask>> Notify Policyholder of Rejection;
endif
:<<SendTask>> Send Settlement Notification;

|Policyholder|
:<<ReceiveTask>> Receive Settlement;
stop
@enduml

Syntax Breakdown: This blueprint highlights how |Claims:Intake|, |Claims:Assessment|, and |Claims:Payout| construct three distinct lanes inside a single Claims pool. Notice how task stereotypes like <<ServiceTask>> and <<UserTask>> explicitly define the exact functional execution for each operational step.

Example 2: E-Commerce Order Fulfillment & Payment Approval

This blueprint maps an online order process across a Buyer, an Online Store backend, and a Warehouse logistics team.
@startuml
title E-Commerce Fulfillment Process BPD

<style>
element {
  MaximumWidth 160
}
</style>

|Customer|
start
:<<UserTask>> Place Order;
:<<UserTask>> Submit Payment Details;

|Store:Backend|
:<<ServiceTask>> Authorize Funds;
if (Payment Successful?) then (yes)
  :<<SendTask>> Send Order Confirmation;
else (no)
  :<<SendTask>> Send Payment Failure Alert;
  stop
endif

|Store:Warehouse|
:<<ManualTask>> Pick & Pack Items;
:<<ManualTask>> Handover to Courier;

|Logistics:Delivery|
:<<ServiceTask>> Update Tracking Status;
:<<SendTask>> Send Delivery Notification;

|Customer|
:<<ReceiveTask>> Receive Package;
stop
@enduml

Syntax Breakdown: This workflow uses early process termination (stop) inside the payment failure branch while keeping the main “happy path” moving seamlessly through backend processing, warehouse execution, and courier delivery.
Scroll to Top