Intro to BPMN (Part 1): The One Task Wonder
An Introduction Into the World of Modeling BPMN
Introduction
Welcome to the first part of my introduction series, that dives into the practical side of BPMN (Business Process Model and Notation). Not just what it is, but how to actually use it to model and improve real-life workflows.
Throughout the series, I’ll be building a process that almost every one of you is familiar with: a vacation request process. It’s something simple, familiar, and a great example of how even the most straightforward processes benefit from clarity, structure, and a bit of automation.
Note, that there is not the one right way to model a process and I will also create some weird requirements, to add the need for certain symbols, so you get a full picture.
We’ll take it one step at a time. Each post will introduce new BPMN elements and solve a specific challenge as the process evolves.
Token Flow
Just a small clarification first, because I will use some process jargon throughout my posts:
In BPMN, the progress of an automated process is represented by a token. Think of it as an imaginary marker that moves through the diagram.
When the process starts, a token is created at the start event and follows the sequence flows, passing through tasks, events, and gateways. Each element it reaches defines what happens next. These elements will e.g. be activated when a token enters, completed when the token takes the outgoing flow, or cancelled if something happens during execution.
Think of the token as a traveler moving along a path: it triggers activities, waits for conditions, and may split or merge at gateways. This concept helps visualize how the process behaves during execution.
A Simple Vacation Process
To begin, we’re keeping things very basic. Here’s the scenario:
An employee submits a vacation request.
The supervisor acknowledges it.
The model for that looks quite simple:
Let’s dive into the different elements.
The BPMN Building Blocks
None Start Event: “Leave Request Received”
This simple circle with a thin, solid border is the trigger for the process.
It means someone (an employee) has submitted a vacation request.
It has no further semantics, therefore it is called a None Start Event.
Start Events have only outgoing sequence flows.
User Task: “Acknowledge Leave Request”
This is called a User Task, which can be assigned to persons or groups.
It means that a human needs to do something. In our case, a supervisor needs to acknowledge the request.
If you automate processes, a User Task is managed in a task list. There, a person can manage all the tasks assigned to them, so effectively see, what they have to do.
User Tasks are by design not automated.
End Event: “Request Processed”
A simple circle with a thick, solid outline marks the end of the process.
It has no further semantics, therefore it is called a None End Event.
End Events have only incoming sequence flows.
Sequence Flows: “The Connection”
Sequence Flows connect Events, Gateways and Tasks.
They define the flow of the process, giving a sequential order to everything that has to happen.
What’s Next?
This simple process already has some benefits for us:
We documented that a supervisor needs to acknowledge a vacation request.
A Supervisor’ll get a task assigned in a task list, instead of receiving individual messages from different sources from their peers.
Even though it’s a simple process, it might not cover the reality. Sometimes it’s not enough to just acknowledge a vacation request, but the supervisor gets some kind of veto right. Also, we want to make sure that the amount of vacation days is tracked in our HR system.
In the next post we will learn how a supervisor can decide if they want to approve or reject a vacation request and make sure that the days taken are updated in our HR system.