The next thing we'll need to add to our process are routes. Routes are typically nodes where decisions are made and, based on the rules of your process, where the flow of the application maybe 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's sake, however, it 's will be best to make it as legible as possible.
...
There is, however, a very important caveat to insert here. Based on the rules above, if the approval value is "accept", the application will route to the HOD. If the approval value is "reject", then an email will 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 will get stuck because there 's is no valid rule to follow. It is due to this that the best practices of decision routing recommends using the Otherwise operator in this given scenario. If we make a slight change to the setting above and put the transition to system as Otherwise, we'll end up with:
...
Note that effectively, the process remains unaltered. If the value of approval is "accept" it will route to the HOD. Any other value , and the email will be sent.
...
NOTE: If done correctly, a plus sign (+) will appear inside your the route.
Joins
Joins usually occur when you have separate paths (usually caused by previous forks) in your process that you intend to merge. In our Leave Application process, once the requestor submits his leave application, both the supervisor and HOD are notified. Once they respond, the application ends up at the back office desk for further processing.
...