The next thing we'll need to add in our process are routes. Routes are typically nodes where decisions are made and (based on the rules of your process), the flow of the application maybe be altered. Strictly speaking, the position of a route in a swimlane doesn't really matter and will not change the logic of your process. For practicality sake tho, its probably best to make it as legible as possible. Before modifying our process, there are 2 general concepts that you should be familiar with when dealing with routes. Given that routes are generally used to affect flow and insert logic and rules into your process, there are 3 types of common constructs for routes. These are:
Decisions
Decisions are used when you want to insert a point in your process, where the flow will be determined by a set of rules. For instance, given our current example, once a requestor submits a leave request, the supevisor will review. The transition from the requestor to a supervisor happens in a straight line (That's to say once a requestor submits, it will always go to the supervisor. There are no other circumstances or conditions in which that will not be true). Now what the supervisor decides to do will cause a decision. The supervisor could choose to accept or reject the application. If the supervisor rejects it, a mail gets sent to the original requestor. Otherwise, it will be forwarded to the HOD.
Given those scenarios, our process will look along the lines of:
Now the scenario above would work but there is a very important caveat to insert here. Based on the rules above, if the approval value is "accept", it will route to the HOD. If the approval value is "reject" then a mail would be sent. However, if a mistake is made in the form or during user input and the value of approval is neither accept or reject, the process gets stuck since there's no valid rule to follow. To that end, the best practices of decision routing recommends that we use the otherwise operator in all circumstances. If we make a slight change to the scenario above, and set the transition to system as otherwise, we'll end up with:
Now effectively the processes remains unaltered. If the value of approval is "accept" it will route to the HOD. Any other value, and the email will be sent.