BPMN Workflow Diagram

What this diagram shows

A BPMN workflow diagram models a purchase order approval process across multiple roles or departments using swimlanes. The flow begins with a purchase request, splits into parallel activities through gateways, passes through decision points (exclusive gateways for amount thresholds), and routes to different approvers (manager, finance, executive) based on order value. Conditional paths merge back together, loop for revisions if rejected, and end at either approval and order creation or cancellation. Swimlanes represent actors (requester, manager, finance team, procurement), while events, tasks, and gateways show what happens, who does it, and which path follows.

Key components

• Start Event — Triggers the workflow when a purchase request is submitted.
• Swimlanes — Vertical or horizontal pools that separate responsibilities by role (Requester, Manager, Finance, Procurement).
• Tasks — Rectangular boxes representing concrete actions like 'Submit Request', 'Review Order Value', or 'Create PO'.
• Exclusive Gateway — Diamond shape that routes the flow based on a single condition, such as order amount under or over a threshold.
• Parallel Gateway — Diamond that splits the flow into simultaneous tasks or merges concurrent paths back together.
• Decision Points — Gateways that reject orders (loop back to requester) or approve them (continue to next stage).
• End Event — Circle shape marking workflow completion, either with approved PO created or order cancelled.

When to use it

Use this template when you need to document approval workflows with multiple stakeholders, conditional routing, and role-based responsibilities. It works well for purchase orders, expense reimbursement, leave requests, change management, or any process where different people approve based on criteria like amount, category, or risk level. BPMN is ideal when you must show parallel activities, loops, and precise handoffs that text descriptions would obscure.

Common mistakes

• Overloading swimlanes with too many tasks, making it hard to follow who owns what and obscuring the actual flow path.
• Using exclusive gateways without clear, unambiguous conditions written on the arrows, leaving readers uncertain which path an order takes.
• Creating loops without a clear exit condition, risking infinite cycles when rejected orders are sent back without defining what must change before resubmission.

Adapting it to your system

Start by listing all roles involved in your approval process and create one swimlane per role. Map out the sequence of checks or approvals required (for example, any order over 5000 needs finance review; over 50000 needs executive sign-off). Replace generic task names with your actual actions and decision criteria. Add any rejection loops, escalation paths, or parallel activities specific to your organisation. Test the flow by walking through examples at different thresholds to ensure all paths terminate correctly.