Process modelling with BPMN

Why Is BPMN the Golden Standard for Process Documentation?

If you've ever had to write several paragraphs of text to explain an organizational process or draw diagrams with colored arrows in PowerPoint, you've certainly faced the problem of inconsistency between teams. Everyone has their own interpretation, details get lost, and when it comes to execution, everything falls apart. BPMN (Business Process Model and Notation) was designed precisely to solve this problem: a standard graphical language managed by OMG that allows you to model processes accurately, unambiguously, and in a machine-executable way.

Unlike simple flowcharts, BPMN doesn't just show the "workflow"; it also covers events, messages, exceptions, and the responsibilities of each role. By learning the core notations, you can document any process — from order registration to complaint handling — in a way that is both understandable for humans and usable by process execution engines (such as Camunda or Activiti).

Core BPMN Notations You Need to Know

BPMN has over 100 notations, but for documenting 90% of organizational processes, you only need a few key ones. These notations fall into four main categories: Flow Objects, Data, Connecting Objects, and Swimlanes.

1. Events: Starting and Ending Points

Events are represented by circles and have three main types:

• Start Event: A circle with a thin line. It indicates the point where the process begins. For example, "Receiving a customer order."
• End Event: A circle with a thick line. It indicates the end of the process. For example, "Shipping the product to the customer."
• Intermediate Event: A circle with a double line. Used to show interruptions or messages that occur in the middle of the process. For example, "Receiving manager approval."

Important note: You can place small markers inside the circle to specify the event type. For example, a letter icon for "receiving a message" or a clock icon for a "time interruption."

2. Activities: The Work That Gets Done

Activities are represented by rounded rectangles and come in two types:

• Task: An atomic piece of work that cannot be further divided. For example, "Checking customer credit."
• Sub-process: A rectangle with a + sign at the bottom. It represents a sub-process that has its own details. For example, the "Order Approval Process," which can include multiple Tasks.

For Tasks, you can also specify their type: a small icon in the top-left corner of the rectangle. For example, a gear icon for an automated Task (Service Task) or a person icon for a human Task (User Task). These details are very important during technical implementation.

3. Gateways: Decision-Making and Branching

Gateways are represented by diamonds and control the process flow. The most common types:

• Exclusive Gateway: A diamond with an × marker. Only one of the paths is selected. For example, "If the order amount is more than 10 million Toman, it goes to the manager for approval; otherwise, it is processed directly."
• Parallel Gateway: A diamond with a + marker. All paths are executed simultaneously. For example, "Simultaneously check warehouse inventory and verify customer credit."
• Inclusive Gateway: A diamond with an O marker. One or more paths are selected based on conditions. For example, "If the customer is VIP, shipping is free; if not, shipping costs are calculated."

Gateways are used both for branching (splitting the flow) and for merging (bringing flows together). In the merge case, the marker inside the diamond is the same, but the direction of the arrows is inward.

4. Connectors

You have three types of connecting lines:

• Sequence Flow: A solid line with an arrow. It indicates the order of activity execution. This line never crosses between two different Swimlanes (for that, messages are used).
• Message Flow: A dashed line with a hollow circle at the start and an arrow at the end. It indicates message exchange between two different participants (e.g., between two departments or two organizations).
• Association: A dotted line. Used to connect data objects or descriptive text to activities.

5. Swimlanes: Defining Responsibilities

Swimlanes are used in two forms:

• Pool: A large rectangle representing a main participant (e.g., "Sales Department" or "Customer").
• Lane: A subdivision within a Pool for different roles. For example, within the "Sales Department" Pool, you can have Lanes for "Sales Specialist" and "Sales Manager."

The golden rule: Each activity must be placed in exactly one Lane. If an activity is shared between two roles, you must split it into two smaller Tasks.

Practical Example: Documenting the "Leave Request and Approval" Process

Let's model a real-world example together. Suppose you want to document the employee leave request process. The steps are as follows:

1. The employee submits a leave request.
2. The system automatically checks the leave balance.
3. If the balance is insufficient, the request is rejected, and the employee is notified.
4. If the balance is sufficient, the request is sent to the direct manager.
5. The manager approves or rejects the request.
6. The final result is communicated to the employee.

Now let's draw these steps with BPMN:

Pool: Employee
  Lane: Employee
    [Start: Submit Request] → [Task: Send Request]

Pool: System (Automated)
  Lane: Process Engine
    [Task: Check Leave Balance] → {Gateway: Sufficient Balance?}
      ├─ (No) → [Task: Auto-Reject] → [End: Notify Employee]
      └─ (Yes) → [Message Flow to Manager Pool]

Pool: Manager
  Lane: Direct Manager
    [Task: Review Request] → {Gateway: Approve?}
      ├─ (Approve) → [Task: Record Approval] → [End]
      └─ (Reject) → [Task: Record Rejection] → [End]

In this model, two Exclusive Gateways are used, and the message flow between Pools is shown with Message Flow. Note that Sequence Flow never goes from one Pool to another; for communication between Pools, we always use Message Flow.

Common Mistake: Using Sequence Flow Between Pools

One of the most common mistakes in BPMN modeling is drawing a Sequence Flow between two different Pools. This is not allowed according to the BPMN standard. Sequence Flow is only used for control flow within a single Pool. If two participants (e.g., "Sales Department" and "Warehouse") need to communicate, you must use Message Flow. This subtle but critical difference matters because, in technical implementation, Sequence Flow means transferring control within one process, while Message Flow means asynchronous message exchange between two independent processes.

Suitable Tools for Drawing BPMN

You don't need expensive tools to get started. Here are a few free and professional options:

• Camunda Modeler: Free and open-source. The best choice for those who want to connect the model directly to an execution engine.
• draw.io (diagrams.net): Free, web-based, and has a complete BPMN library. Great for quick documentation.
• Bizagi Modeler: Has a free version and is simpler for non-technical teams.
• Visual Paradigm: Professional and paid, but also has a Community Edition.

If you work in a Linux environment and prefer command-line tools, you can edit BPMN files as XML. A simple BPMN file starts like this:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                   id="Definitions_1" targetNamespace="http://example.com">
  <bpmn:process id="Process_1" isExecutable="true">
    <bpmn:startEvent id="StartEvent_1" name="Start"/>
    <bpmn:task id="Task_1" name="Review Request"/>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="StartEvent_1" targetRef="Task_1"/>
  </bpmn:process>
</bpmn:definitions>

This XML structure is exactly what process execution engines read. So if your model is correct, you can directly deploy it for execution.

Professional Tips for Effective Documentation

A good BPMN model isn't just about "drawing"; it's a living document that must be maintainable. Follow these tips:

• Choose the level of detail appropriate for the audience: For senior managers, a high-level model with Sub-processes is sufficient. For the technical team, you need to go down to the Task level and even Data Objects.
• Use consistent naming: Start activity names with a verb ("Check," "Register," "Send") and avoid vague verbs like "do."
• Always write the Gateway condition on the line: Write the condition on each Sequence Flow leaving a Gateway (e.g., "Yes" / "No" or "Amount > 10 million"). Without these conditions, the model cannot be interpreted.
• Use Data Objects to show inputs/outputs: If a Task requires specific data (e.g., a "Request Form"), connect it to the Task using a paper rectangle (Data Object).
• Validate the model with stakeholders: Before finalizing, show the model to the people who actually do the work. You'll often discover that you've missed an exception or an alternative path.

Common Mistake: Overly Complex Modeling

If your model has more than 15-20 elements at one level, it's probably too complex. The solution: use Sub-processes. For example, instead of laying out 10 Tasks related to "Order Approval" in a row, create a Sub-process called "Order Approval" and explain the details in a separate diagram. This greatly improves readability and makes the model easier to maintain.

From Model to Execution: The Next Step

Documenting with BPMN isn't just about "drawing a map." If you follow the standard correctly, you can feed the same model to a process execution engine (like Camunda or Flowable) and run the process automatically. This means your model is not just a document, but an executable program. To get started, focus on a small, high-frequency process (like leave requests or complaint registration), model it carefully, and then move on to more complex processes.

If you're looking for infrastructure to run these models, ServerNet offers hosting services and cloud infrastructure where you can deploy process execution engines. But your main focus should be on learning BPMN itself; the tools and infrastructure come later.

Finally, remember that BPMN is a language, not a goal. The ultimate goal is to clarify processes, eliminate ambiguities, and create a common language between technical and non-technical units in the organization. With practice on real-world examples, you'll quickly master this language.