The next thing we'll need to add in 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 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's sake thothough, its it's 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 They 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 examplein our Leave Application process, once a requestor submits a leave request, a review by the supevisor supervisor will review. The be required. You will see in the figure below that the transition from the requestor to a supervisor happens in a straight line (That's to say once , which tells us that whenever a requestor submits a request, it that request will always go to the supervisor . There and there are no other circumstances or conditions in which that will not be true).
Now, what the supervisor decides to do will cause result in a decision. The supervisor could : either choose to accept or reject the application. If the supervisor rejects it, a mail gets will be sent to the original requestor. Otherwise, it the application will be forwarded to the HOD.
Given those scenariosthe above, our process will look along like the lines offigure below:
Now the scenario above would work but there is There is, however, a very important caveat to insert here. Based on the rules above, if the approval value is "accept", it the application will route to the HOD. If the approval value is "reject" then a mail would , 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 gets will get stuck since because there's no valid rule to follow. To that end, It is due to this that the best practices of decision routing recommends that we use using the otherwise Otherwise operator in all circumstancesthis given scenario. If we make a slight change to the scenario setting above , and set put the transition to system as otherwiseOtherwise, we'll end up with:
Now Note that 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.
...
A fork is used when your process needs to split separate ways concurrently. That essentially mean , meaning that your process is now travelling to along 2 separate paths (hence, "fork"). Lets Let's say, for an instance, that in our given example, once the requestor submits his leave application, a notification gets sent to * both * his supervisor and the HOD at the same time. If that was is the case, we'll need to add a route, set the split type to "and" and our process will look like:
NOTE: If done correctly, you'll see a little plus sign (+) show up in will appear inside your route.
Joins
Joins usually occur when you have separate paths (usually caused by previous forks) in your process that you intend to merge. Lets expand our example a little father. Once the requestor as In our Leave Application process, once the requestor has submitted his leave application, the both the supervisor and HOD are notified. Once they have respondedrespond, the application now ends will end up at the back office desk for farther further processing. Now there
There are 2 types of joins available to you:
- XOR (or exclusive ORs in geek talk) . Means means that the route is active and considered fulfilled once *any* of the transitions reaches it. Effectively, So if you use the XOR option in your join route, the back office will be notified the moment either the supervisor or HOD responds.
- AND . Means means that the route will hold in wait for *all* the transitions to complete reaching it. Effectively, be completed. So if you use the AND option, the back office will only be notified once if and when both the supervisor and the HOD respondshave responded.
In any caseTo sum it up, once we understand the essential route concepts, we'll move back to our application. Now we know that once the requestor submits an application, the supervisor will decide on whether to approve or reject. If the supervisor approves, it the application will go to the HOD for approval. Given those circumstances, there are clearly 2 routes we'll need. One Two routes are needed here: one for when the supervisor approves and one another for when the HOD approves. Again, while the position of the routes in specific swimlanes doesn't really matter, there's much to say for keeping our process legible; so after it is ideal to keep the process legible.
After adding the routes, your the process should look like:
...