Intro to BPMN (Part 2): Your Vacation Request has Been Approved!
Give Your Processes More Meaning With Simple Decisions.
In the last post, I introduced you to a simple vacation process, where a supervisor gets informed about the vacation request of an employee. The process was simple, but lacked important tasks.
Some companies require supervisors to verify the request and approve or reject it afterwards, based on the verification outcome. In case of approval, the amount of vacation days needs to be deducted from the employee’s account. In case of a rejection, information has to be sent to the employee, so they can react to the decision: book the vacation or rearrange the trip on another date (or hand in their resignation…).
Adding a Simple Decision
Here’s the scenario:
A supervisor reviews the request, just like before.
They need to decide if the request is approved or not.
In case of approval, a human has to update the HR system.
In case of rejection, a mail has to be sent to the employee, informing them about the decision.
The model below shows how the process could look like. New elements are green, to make changes to the former model transparent.
Now, the supervisor has the choice of how the process continues, based on their review. In case an employee has too few days left, the process now has a separate branch dealing with the rejection.
The process also supports an update of an external system. Even though it is a manual task, the model makes this step visible for the reader: “In case of approval, the HR system has to be updated with the vacation days left for the employee.”
The BPMN Building Blocks
Exclusive Gateway: “Request Approved?”
Exclusive Gateways model a decision where only one of the outgoing flows can be taken. It is also called an XOR (Exclusive OR) Gateway, since it picks exactly one outgoing flow.
It is also used to merge several flows into one. Technically, it will not wait for all incoming tokens, but continues the flow for each token that passes through the gateway, as it is usually used to merge an XOR split, back into a single flow, so there shouldn’t be more than one token.
What’s Next?
Our process just got a bit closer to reality:
A supervisor has the possibility to actively reject a request.
It is defined, that an update to the HR system has to be done.
We ensure that a message is sent to the employee about the rejection.
But just like before, this covers only parts of reality. Who is responsible for all these tasks? We only see some user tasks, but it could be that multiple parties are involved, like the supervisor or even someone from HR.
In the next post, you’ll learn about roles and responsibilities in a process model, with collaboration pools and lanes.