Intro to BPMN (Part 5): Time Is Money!
Make Sure Your Processes Are Not Blocked.
Last time, we improved our process model to enable communication between different pools in your organization. Today I want to improve the quality of our process.
Imagine the supervisor of an employee is on vacation. All vacation approvals are now in a waiting state, since no one is there to handle them. Isn’t there a way to improve this? Sure! Let’s take a look.
Adding Escalation to Our Process
Here’s a solution to our absence scenario:
Vacation requests have to be processed within 1 day.
If it takes longer, the supervisor gets a friendly reminder.
If it takes longer than 4 days (in case there is a weekend in between), we delegate the task to the department head.
The model below shows, how the model could look like. As usual, new elements are marked green.
Now, there are two new elements attached to the manual task, indicating some time restrictions. They lead to follow-up tasks for the supervisor and the department head. Let’s look at them one by one.
The BPMN Building Blocks
Escalation Boundary Event (Interrupting)
Boundary Events are a type of Intermediate Events (with a double solid border) which means, they are neither Start nor End Events.
They are always catching (not throwing) events. They are triggered by an event thrown during the execution of the task they’re attached to, and have an outgoing flow.
If it catches the event, the task is interrupted. The task is no longer active and outgoing flows from the task are cancelled.
Escalations are used to escalate the flow to a higher instance, if certain constraints are not met. In our case we escalate the flow, when a vacation request is not reviewed after 4 days.
Timer Boundary Event (Non-Interrupting)
A Boundary Event can also be non-interrupting. This means, that in case the event is caught, the task it is attached to, continues. This also means, that there can be two active flows. One for the finished task, and one for the boundary event.
Timers are used to wait for a certain amount of time. In our case, the timer creates an event after 1 day. This event has no further semantic meaning. It just signals that a certain amount of time has passed.
What’s Next?
Now we have the possibility to react to time semantics:
It is ensured that a process only waits for a certain amount of time.
We use non-interrupting semantics for reminders, with the goal to continue the process flow.
We use interrupting semantic to cancel a task and take another route.
Now that we ensure that the flow continues in a timely manner, we can take a look at the details of our review process. A review can contain of many different steps.
In the next post we will learn about sub-processes and how they can group functionality and keep complex models simple.