|Model the happy path to the desired end result (Step 1) before collecting problems and exceptions, prioritizing them and introducing them incrementally by focusing on one selected issue at a time and choosing the right techniques for modeling "beyond the happy path" (Step 2).|
For modeling the happy path one should define the desired end result, find a suitable start event, and collect the activities and external dependencies which always need to be considered to reach the result.
When we have that, the diagram shows the Happy Path of a business process (or of the selectively chosen part of the end-to-end business process):
|1||End Event: It’s often the easiest first step to agree upon the desired ("happy") end result of a process.|
|2||Start Event: As a second step one might agree upon a trigger for the work leading to the end result.|
|3||Activities: After that, you can brainstorm and collect activities which always need to be carried out to reach the result.|
|4||Intermediate Events: Optionally, you can brainstorm and collect milestones (modeled as blank events) and important external dependencies (e.g. modeled as message events).|
Focus on one particular, selected problem.
Try to understand the worries for the business in the light of the desired end result.
Identify the undesired end result the process will reach in case the problem cannot be mitigated. This informs you about the end event you will eventually reach because of the problem.
Identify the affected areas in the happy path: can the problem occur at a particular point, during (one or several) activities or basically all the time? This will inform you about the most promising modeling technique for the problem: whether either gateways, boundary events or event based sub processes can serve you to fork off your "problem path".
With BPMN gateways we can deal with problems arising at a particular point in our process.
By using data-based gateways we actively decide "now and here" on the basis of our own process data which path our process must move along. Therefore we can e.g. use a XOR gateway to fork off a "problem path" dealing with a problematic result of our own activities:
|1||The exclusive gateway deals with the potentially problematic result of incomplete order data. Note that we deal here with the procedural consequences of work which already took place in the preceding task, where we actually checked the order for completeness.|
|2||Again, the preceding task already dealt with the actual work of checking, here the customer’s creditworthiness. The result of the task is a yes or no (true or false). We can deal with data by means of a data based gateway which immediately redirects to the path our process must move along.|
|3||The end event characterizes the undesired end result "order declined" which we now reach because of having modeled two problems. In the example both of them lead to one and the same business outcome.|
By using event-based gateways we passively wait for future events deciding about which path our process will have to move along. Therefore we can e.g. use use it to fork off a "problem path" dealing with an undesired event outside of our own control:
|1||After having requested a delivery date (e.g. from wholesale), we use an event based gateway to passively wait for what happens next. We can not know "now and here", because it’s outside of our own control.|
|2||The intermediate message event allows us to deal with the undesired event that the ordered good is not deliverable.|
By using event-based gateways we can also deal with the situation that nothing relevant for our process happens. We do this by defining a time period, after which we decide that we do not want to wait any longer:
|1||The intermediate timer event allows us to deal with the situation that nothing relevant for our process happened for a defined time period. In case we do not get an answer from wholesale, we inform the customer, that the order is not deliverable at the moment.|
With BPMN boundary events we can deal with problems arising while we are actively occupied to carry out work in our process.
A typical case is that it turns out to be impossible to achieve the result of an activity while working on it. We can then choose to interrupt our work and fork off a "problem path" to deal with the issue:
|1||The interrupting boundary error event allows us to deal with the fact that the order is not even readable. As this prevents us from properly judging the completeness of the order, we cannot reach one of the expected results of our activity ('complete' or 'not complete'), but instead deal with the problem by interrupting the activity and assuming the order to be declined.|
When modeling for business process automation, "dealing with errors" might be a highly technical concern. As a rule of thumb, we just want to show the "business related" problems in a process model: those problems and errors which cause that our business process must move along a different path, because different work must be carried out as a reaction.
|An example for a typical technical concern would be that we currently cannot reach a system, which is why we e.g. want to re-attempt it another time later on. We do not show such purely technical problems in a business process diagram, not even in an executable one: (1) it would clutter the diagram and (2) there are more suitable ways to deal with technical issues potentially occuring almost anywhere. Read our Best Practice about Dealing With Problems and Exceptions from a more technical point of view in order to learn more about the border in between business related shown in a process diagram and purely technical concerns not shown in a process diagram.|
Another typical use case for reacting to situations while we are actively occupied is that it sometimes turns out that we need to do stuff in addition to what we already do:
|1||We encapsulate part of our process into a subprocess to enable us to express that while we are occupied with that part of the process, additional work might pop up.|
|2||The non-interrupting boundary timer event allows us to speed up order preparation in case it takes longer than two days, e.g. by informing a responsible manager.|
With BPMN event sub processes we can can - a bit similar to boundary events - deal with problems arising while we are actively occupied to carry out work. The main advantage when being compared with boundary events, is, that some issues can occur almost anywhere on our way through the happy path.
Some issues can occur almost anywhere on the way through our process. The event sub process allows us to fork off a problem path modeled separately from our main process to deal with such issues:
|1||The non-interrupting start message event of the event sub process allows us to express that wherever we currently are on our way through order confirmation, it can happen that the customer requests information about the status of that process.|
|2||We should then provide the requested information without interferring with the order confirmation process itself.|
Another typical use case for event based sub processes is a cancellation requested by the customer:
|1||The interrupting start message event of the event sub process allows us to express that wherever we currently are on our way through order confirmation, it can happen that the customer requests cancellation.|
|2||We should then interrupt the main process (which is already expressed by the nature of the start event) and inform an involved dealer.|
BPMN allows to model activities which wait for responses instead of showing that waiting with separate message events. This has the advantage that you now can leverage boundary events to deal with missing results or other events occuring while you are waiting for the response. This is an alternative to using the event based gateway shown in all the other models:
|1||Instead of modeling an event for receiving a delivery date, we model a task here.|
|2||The fact that we do not receive such an answer at all can now be modeled as an interrupting boundary timer event: we inform the customer about the status, but as the timer is interrupting do not wait any longer for the delivery date.|
|3||The possibility that it now might turn out that the ordered good is not deliverable could also become a boundary event, e.g. a boundary message event: the undesired event prevents us from sucessfully receiving a delivery date, we therefore cancel any further waiting but instead inform the customer about the status.|
Boundary Events are particularly useful when you consider that you might want to remind your dealer that the answer is overdue and give him another chance for transmitting the delivery date before you give up waiting.
First, consider how this could be achieved by using event based gateways:
|1||After having realised that the dealer’s answer is late, we decide whether we want to remind the dealer and continue to wait - or not. We modeled here, that we want to remind the dealer just once.|
|2||However, note that while we are reminding the dealer, we are strictly speaking not in a state "ready-to-receive" the dealer’s answer! According to BPMN execution semantics the dealer’s message might get lost until we are back at the event based gateway. While you might want to choose to ignore that when modeling for communication purposes only, you will need to get it right for executable models.|
To get the BPMN execution semantics above fully right, we would now need to attach the two possible answers of the dealer ('Delivery data fixed', 'Ordered good not available') as boundary events to the task 'Remind dealer', too! Quite a modeling construct, just to properly wait for the dealer’s response, right? Therefore, consider the following alternative to this modeling issue using boundary events only:
|1||Modeling a non-interrupting boundary timer event directly at a task which waits for the response has the advantage that we never leave the "ready-to-receive" state and therefore avoid troubles with the strict interpretation of BPMN execution semantics.|
|The second alternative is very compact and avoids issues with not being ready-to-receive, but typically needs a deeper understanding of BPMN symbols and their consequences for the token flow. Therefore we sometimes also prefer event based gateways for showing human flows and ignore sophisticated token flow issues as discussed here.|
When using the Camunda BPMN Framework as described in great detail in our book Real Life BPMN, it is important to understand that a happy path will typically be modeled "per pool" - in other words in an operational level collaboration diagram, you will typically model several happy pathes - from point of view of each participant.
We distinguish between models on a strategic level and on an operational level. The Camunda House illustrates the relationship between those two models.
While the Camunda House’s roof represents a rough overview of the process from a bird’s eye view, the house itself represents the operational process as it looks like from a worm’s eye view, to which belongs a human perspective of the operational process participants as well as a technical perspective showing the internals of involved IT system(s).
For strategic purposes, we typically model one expanded pool showing the organisation’s process participants as individual lanes within that pool:
The happy path of this strategic level process would just affect the lane of the call center - when being able to deal with the customer’s issue itself. Therefore, we often add the strategically relevant problems and exceptions on a strategic level, too. Typically these are exceptions which lead to the involvement of new organizational roles, which would remain unseen otherwise, or lead to important new rights or responsibilities of those roles, which would remain unseen otherwise.
For operational purposes, we typically model a collaboration diagram with several pools: (at least) one for each human process participant and each involved IT system:
When modeling the happy path on an operational level as well as problems and exceptions "beyond the happy path", it is important to understand that this applies now to each individual participant’s end-to-end process "fragment", in other words to each individual pool shown in the collaboration diagram.
Therefore, on an operational level, we will go through the two modeling steps of (1) modeling the happy path and (2) modeling the problems and exceptions not just once - as we did for the strategic level - but rather several times: once for each expanded pool, in other words once for each process participant’s perspective. Ask yourself two questions from each process participant’s perspective: (1) how does the process move on in case everything goes smoothly and (2) which problems and exceptions might occur along that process participant’s involvement.
No guarantee - The statements made in this publication are recommendations based on the practical experience of the authors. They are not part of Camunda’s official product documentation. Camunda cannot accept any responsibility for the accuracy or timeliness of the statements made. If examples of source code are shown, a total absence of errors in the provided source code cannot be guaranteed. Liability for any damage resulting from the application of the recommendations presented here, is excluded.
Copyright © Camunda Services GmbH - All rights reserved. The disclosure of the information presented here is only permitted with written consent of Camunda Services GmbH.