Your first step of Questetra BPM Suite / Chpt.4: Splitting by Condition

Chapter 4: Splitting by Condition

In Chapter 3 we added the Boss Swimlane allowing the applicant’s supervisor to participate in the travel request process. When that happens, you might start having ideas to improve the App, such as whether or not it is sufficient for the supervisor to just look over the request. For the final instalment of this tutorial, I will introduce you to the implementation of splitting, which changes the token’s destination according to the conditions. This will greatly enhance the expressive power of the App.

Making the Boss able to Reject the request

In the current state a travel request cannot be rejected. The supervisor should be able to choose whether to approve or reject a request after reading its contents in the Approve Task. Let’s create this option.

Editing Workflow diagram

Launch the Modeler and open the Workflow Diagram tab. Then add an End Event to the Boss Swimlane and draw a flow arrow from the Approve Task towards the End Event.

When you added the flow arrow it created a branch, so the destination of the token depends on the supervisor approving or rejecting it. “Approve” and “Reject” are the names of the button labels displayed at the bottom of the task processing form. Since they are not displayed immediately after adding the flow let’s set the button labels.

Setting up the button labels

Now let’s set the display labels of each button. Open the settings window of the Approve Task. When you move to the Split tab, you can see the Button Label settings item there.

Set the name of the button whose destination is Confirmation to “Approve”. Similarly, for the destination End Event, set this label to “Reject”. By doing this, when the supervisor finishes handling the Approve Task by clicking on the Approve button, the token will transit to the Confirmation Task, and by clicking the Reject button it will go to the End Event on the Boss Swimlane. Now save the App and release it.

If Canarias makes a travel request for example, and Sumatera, who is Canarias’ supervisor, opens the Operating screen of the Approve Task, it will look like the above figure. Try clicking on the newly created Reject button.

The token advanced to End Event on the Boss Swimlane and the Process has ended. In this way you can change the destination of the token by using the options. This is one way of implementing a split.

Practically, it would be better that if the supervisor rejects a request, it is returned to the applicant. However, for the sake of simplicity I made this example so that the Process is terminated when rejected.

Letting the company president check requests with high costs

Finally, let’s modify the App so that it requires confirmation by the president of the company on requests for expensive business trips that will cost more than $10,000. Please open the edit screen as we are going to revise the App again.

Editing the Workflow diagram

Modify the Workflow diagram as follows; we will add a President Swimlane and make substantial changes after the Approve Task. Let’s see the procedure in detail.

First, add a new Swimlane between Boss and Management Department. Then change its name to “President”. Also, add a Task to the President Swimlane and name it “Confirmation”.

The green diamonds labelled “Split” and “Merge” in the above figure are referred to as Gateways. They control the splitting and merging of flows. Gateways are also contained in the pallet.

When you click ▼ next to the diamond icon the list of Gateways is expanded. You can add various Gateways to a Workflow diagram by choosing the icon. The following two Gateways are used this time.

Exclusive (XOR) GatewayAdvance to the branch which satisfies the condition first among multiple flows
Join GatewayMerge multiple split flows into one

Place an Exclusive (XOR) Gateway onto the President Swimlane, and a Join Gateway onto Management Department. Since the Join Gateway you just deployed is not named open the settings window just like any other object and set the name to “Merge”.

It is correct if the objects are arranged as in the above figure.

All we have to do is to redraw the flow arrows. Upon doing so, please be careful not to inadvertently move the flow extending from the Approve Task in the Boss Swimlane. The Reject and Approve flows set earlier have been given specific branching conditions. Since deleting or rerouting the root of the flow (on the Approve Task side) will delete the Split condition setting you will have to set it again. In particular, please do not delete and redraw the Approve flow. Drag and drop the arrowhead of the flow.

Taking note of the above let’s draw flow arrows to look like the figure below.

After redrawing all the flow arrows, check if the names of the flows extending from the Approve Task remains as “Reject” and “Approve”. If a flow arrow is deleted or its root is removed from a Task, the splitting condition is deleted and the labels will disappear. If that happens, please re-establish the splitting condition you set previously. Remember to reset the button label for the splitting condition.

Setting the Splitting condition

Next, set up the newly created split. Open the settings window of the Exclusive (XOR) Gateway. There you can set the destination of the token for each condition in the Destination Node section.

ConditionDestination
Travel cost is more than $10,000Confirmation Task on the President Swimlane
OthersMerge Gateway on the Management Department Swimlane

It seems that the App will behave as desired if you can set up as the above table. As there are two conditions and a Default Flow from the beginning let’s edit those. A Default Flow is what will be selected when none of the conditions is satisfied. Thus, it will be sufficient if you set the condition “Amount is over $10,000” and a Default Flow. The Default Flow serves the role of “Others” shown in the above table.

First, delete one of the conditions whose destination is Merge, since it is sufficient to have only one condition and a Default Flow. Next, change the destination of the Default Flow to Merge. With these, you have set up the “Others” condition.

And in the other condition whose destination is Confirmation, the condition has been set as “Always move to Destination”. You must change it so it will move to that destination if the Amount is greater than or equal to $10,000. Click on the pencil symbol to open the details window and set it up as follows. Enter “condition1” as the condition name.

It has been set so that when the value of the Data Item “Amount” is over 10000, that is, the travel cost exceeds $10,000, the token moves to the Confirmation Task on the President Swimlane. Now, you can control the transition of the token as shown in the table above.

Please confirm that the Split tab properties are like the above figure. There is nothing to set in Merge (the Join Gateway). Now you have completed the Workflow diagram!

Setting the Operator

After finishing editing the Workflow diagram you will set up the Operators next. In the President Swimlane settings window, change the Operator to Organization > 00 COMPANY NAME > Leaders who belong to this. Since the top Organization of the company is 00 COMPANY NAME, the leader of it represents the President.

Now save and release it, and try making a request with a cost of more than $10,000 as an employee. Like before, the Approve Task will be delivered to the immediate supervisor. When the supervisor approves it, the Confirm Task will be delivered to you as the president of the company.

Does the App you created work properly? Once you have created the App it automatically processes the designation of the immediate supervisor, and whether the president needs to give confirmation or not. The log of who operated which Task and when can be confirmed later.

This is the end of the Questetra BPM Suite Tutorial for beginners. I introduced only the rudimentary functions of Questetra BPM Suite, but how was it? I hope you will meet your challenges for the automation and visualization of business rules which are repeated every day using Questetra BPM Suite!

2 thoughts on “Your first step of Questetra BPM Suite / Chpt.4: Splitting by Condition”

  1. Pingback: Your first step of Questetra BPM Suite / STEP3: Creating Travel Request App – Questetra Support

  2. Pingback: Human Task – Questetra Support

Comments are closed.

%d bloggers like this: