BPMN Explained Simply: Notation and First Diagrams

If you have ever tried to explain a business process to a colleague and ended up drawing arrows on a whiteboard, you have already reinvented — very roughly — BPMN. Business Process Model and Notation is the international standard for representing processes visually in a way that is readable by everyone involved, from business teams to developers. This guide covers the essential elements and walks you through building your first diagram.

What Is BPMN and Why Use It?

BPMN (Business Process Model and Notation) is a standard published by the Object Management Group (OMG) that provides a graphical notation for representing business processes. The current version, BPMN 2.0, is supported by the vast majority of modelling tools.

Why choose BPMN over a homegrown flowchart?

• Interoperability: any BPMN-trained professional can read your diagram, whether they are on your team or at a partner organisation.
• Precision: each symbol carries a defined meaning, eliminating the ambiguity that tends to creep into ad-hoc notations.
• Path to automation: workflow engines such as Camunda, Flowable, and Activiti can execute BPMN 2.0 diagrams directly.

For SMEs and mid-market companies looking to map their processes and link them to their IT landscape, BPMN provides a shared language between business and IT teams. That is exactly what the UrbaHive process editor is designed to support.

The Four BPMN Element Families You Need to Know

1. Events

Events mark significant moments in the life of a process. There are three main types based on their position in the flow:

• Start event (thin circle): triggers the process. Example: "Customer order received."
• Intermediate event (double-bordered circle): occurs during the process. It can either trigger an action or be the result of one. Example: "Approval deadline exceeded."
• End event (thick circle): marks the end of the process or a branch. Example: "Order shipped."

Events can also carry internal markers: an envelope for a message, a clock for a timer, a lightning bolt for an error, and so on.

2. Activities

An activity represents work being performed, whether manual or automated.

• A task (rounded-corner rectangle) is the base unit. It can be qualified by type: user task (performed by a person), service task (executed by a system), script task, and so on.
• A sub-process (rounded-corner rectangle with a small "+" at the bottom) encapsulates a sequence of activities that you do not want to detail at this level of the diagram.

A practical rule for SMEs: keep each task to a single responsibility, expressed with an action verb in the imperative or infinitive form — "Check stock availability," "Send invoice."

3. Gateways

Gateways (diamond shapes) control how flows diverge and converge.

• Exclusive gateway (XOR): only one path is taken based on a condition. Symbol: empty diamond or one marked with an "X."
• Parallel gateway (AND): all paths are taken simultaneously. Symbol: diamond marked with a "+."
• Inclusive gateway (OR): one or more paths are taken based on which conditions are met. Symbol: diamond marked with an "O."

The exclusive gateway is the most commonly used. Example: "Is the item in stock?" → Yes → "Prepare shipment" task; No → "Notify customer of delay" task.

4. Connecting Objects

• Sequence flow (solid arrow): connects elements in execution order within the same participant.
• Message flow (dashed arrow): represents an exchange of information between two separate participants (two pools).
• Association (dotted line): attaches an artefact — annotation or data object — to a diagram element.

Containers: Pools and Lanes

A pool (large enclosing rectangle) represents a process participant: an organisation, a department, or a system. Inside a pool, lanes (horizontal or vertical bands) distribute activities by role or function.

Example: a pool "Recruitment Process" with three lanes — "HR Manager," "Hiring Manager," and "Candidate." Each lane contains the tasks for which that role is responsible.

This structure is directly linked to the concept of process ownership. In UrbaHive, every process and every step is assigned to an identified actor, which enables automatic detection of ownerless processes — one of the most common operational risks in SMEs.

A Sample Diagram: Leave Request Processing

Here is the description of a simple two-lane BPMN diagram:

Pool: Leave Management

• Lane "Employee": Start event (Request sent) → Task "Fill in leave form" → Task "Submit request" → Intermediate event (Awaiting decision)
• Lane "HR Manager": Task "Receive request" → Task "Check leave balance" → Exclusive gateway "Sufficient balance?"

- Yes → Task "Approve request" → End event (Leave granted)

- No → Task "Send rejection notice" → End event (Request declined)

This diagram uses fewer than ten elements yet clearly shows responsibilities, decision points, and failure paths. It can also serve as the starting point for automation.

Best Practices for Your First BPMN Diagrams

Start at level 0. Do not try to capture every edge case in your first diagram. Model the happy path first, then add error branches in a subsequent revision.

Name elements explicitly. Activities use action verbs ("Validate," "Send," "Verify"). Events describe a state ("Order received," "Deadline exceeded"). Gateways carry a closed question.

One pool per participant. Do not mix two organisations or two systems in a single pool. If an external party is involved, create a second pool and connect the two with message flows.

Read the diagram aloud. If you cannot describe each activity's flow in a single sentence, the granularity is probably off — too fine or too coarse.

Link tasks to the applications that support them. This is the step that turns process modelling from a documentation exercise into a real management tool. In UrbaHive, each process step can be linked to one or more applications from your IT landscape map, enabling the platform to calculate automatable hours and flag operational risks.

BPMN and the UrbaHive Process Editor

UrbaHive includes a visual process editor that draws on BPMN conventions to stay accessible to non-technical profiles while maintaining the rigour needed for structured analysis. Each step is qualified by its execution mode (manual, assisted, or automated), its duration, and its owner. The dashboard then computes an optimisation score and a monthly automatable-hours volume.

This approach is covered in detail in our business process mapping guide and in the article on step-by-step mapping methodology.

Conclusion

BPMN is not reserved for enterprise architects or BPM specialists. With four element families — events, activities, gateways, and flows — and a handful of naming rules, any team can model its processes rigorously and in a way that everyone can share and read. The real value is not the diagram itself but what you do with it: spotting bottlenecks, detecting risks, measuring automation potential, and aligning your teams around a common reference.

Start for free on UrbaHive and model your first process in minutes with the built-in process editor.

FAQ

Q: Do I need to be BPMN-certified to use the notation?

A: No. Certifications such as OCEB2 or BPM CBOK are useful for large-scale projects, but mastering the basic elements covered in this article is sufficient for mapping everyday SME processes.

Q: What is the difference between a BPMN diagram and a classic flowchart?

A: A flowchart is a generic notation without strict semantics. BPMN is a formalised standard: every symbol has a precise meaning, ensuring that all trained readers interpret it the same way.

Q: Can a BPMN diagram be exported to a workflow engine?

A: Yes, if your tool exports in BPMN 2.0 XML format. Engines such as Camunda or Flowable can read that file and execute the process automatically. UrbaHive focuses on mapping and analysis; for execution, integration with a dedicated engine is recommended.

Q: How many activities should a BPMN process contain?

A: There is no formal limit, but a readable diagram typically contains between 5 and 20 activities. Beyond that, it is better to use sub-processes to manage complexity.

Q: Is BPMN suitable for highly technical or IT processes?

A: BPMN describes business processes, not internal technical flows within a system. For interactions between application services, notations such as ArchiMate or UML sequence diagrams are better suited. See our ArchiMate guide for more.