Process Routes

Introduction

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 application flow may be altered. Strictly speaking, the position of a route in a swimlane doesn't matter and will not change the logic of your process. However, it will be best to make it as legible as possible for practicality's sake.

Types of route constructs

Routes are generally used to affect the flow and insert logic and rules into your process, so there are three types of common constructs for routes.

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, in our Leave Application process, a review by the supervisor will be required once a requester submits a leave request. You will see in the figure below that the transition from the requester to a supervisor happens in a straight line, which tells us that whenever a requester submits a request, that request will always go to the supervisor. There are no other circumstances or conditions in which that will not be true.

Now, the supervisor's decision will result in either accepting or rejecting the application. If the supervisor rejects it, a mail will be sent to the requester. The application will be forwarded to the HOD if the supervisor accepts it.

Given the above, our process will look like the figure below:

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, 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 is no valid rule to follow. Due to this, the best practice of decision routing is to use the Otherwise operator in this given scenario. If we make a slight change to the setting above and put the transition to the system as Otherwise, we'll end up with:

Note that effectively, the process remains unaltered. If the approval value is accept, it will be routed to the HOD. Any other value and the email will be sent.

Forks

A fork is used when your process needs to split ways concurrently, meaning that your process will travel along 2 separate paths (hence, fork). For instance, in our given example, once the requester submits his leave application, a notification is sent to both his supervisor and HOD simultaneously. If that is the case, we'll need to add a route to set the split type in and, and the process will look like this:

A plus sign (+) will appear inside the route if done correctly.

Joins

Joins usually occur when you have separate paths (usually caused by previous forks) in the process you intend to merge. In our Leave Application process, the supervisor and HOD are notified once the requester submits his leave application. Once they respond, the application ends up at the back office desk for further processing.

There are 2 types of joins:

1.  XOR (or exclusive ORs in geek talk) means the route is active and considered fulfilled once any transition reaches it. So, if you use the XOR option in your join route, the back office will be notified when either the supervisor or HOD responds.

2. AND means that the route will wait for all the transitions to be completed. So, if you use the AND option, the back office will only be notified if and when both the supervisor and the HOD have responded.

In summary, once the requester submits, the supervisor will decide whether to accept or reject it. If the supervisor accepts, the application will go to the HOD for approval. Two routes are needed here: one for when the supervisor approves and another for when the HOD approves. Again, while the position of the routes in specific swimlanes doesn't matter, it is ideal to keep the process legible.

After adding the routes, the process should look like: