Last time, we learned to keep our process model simple by embedding processes into a Sub-Process, or use a Call Activity to reference an external model. In this article I want to highlight, how errors can be handled and how different semantics can lead to totally different process models.
Handle The Errors That You Know
Here are the requirements for our new process:
Vacation day checks are now automated by a service.
If the remaining vacation days are insufficient for the request, it will be rejected automatically.
Our HR API returns an error, if the amount of requested days is higher than the remaining days.
The model below shows, how the model could look like. As usual, new elements are marked green.
Note: I keep the Sub-Process for visualization reasons, even though I said that Call Activities would be the way to go to prevent duplication.
The BPMN Building Blocks
Error Boundary Event (Interrupting)
Error Boundary Events are used to catch errors and diverge the process flow to an alternative path. Just like all Boundary Events, it has a solid, double border. Inside the event is a small, empty lightning symbol. This means it is catching an error.
It can be attached to every kind of Task or Sub-Process.
Error Events can only be used as Error Start Events in an Event Sub-Process (which we will deal with later), or Error Boundary Events to catch errors, or Error End Events to throw errors. They are always interrupting.
Service Task: “Check Leftover Vacation Days”
Service Tasks symbolize a task that is automated by a system. There is no human interaction necessary. The task has two small gears in the upper left corner.
The tech behind it could be anything. An AI agent, a program writing data to a database, or some other API.
Many Roads Lead to Rome
There are of course other ways to solve the vacation day issue. One could argue that it is not an error, but we could just read the number of left over vacation days, do some math on the numbers, and use an Exclusive Gateway to continue, based on the result:
It depends on the semantics: Is it an error if someone requests more days than available? In our case it is an error, since the API returns an error when called with an invalid amount of vacation days. It could also be, that in your case it is just not, and your API returns something else.
What’s Next?
Our model just got automated, and we are listening to errors that might occur:
When to few vacation days are available, we use an error to diverge the flow into a rejection.
We also learned that there are many ways to solve a certain issue. It all depends on the semantics of your process.
In the next post we want improve the user experience a bit, by allowing employees to change their mind.