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

Chapter 4: “Splitting” by Condition

In Chapter 3, we have added the Swimlane of “Boss” so that the Boss of the applicant became able to participate in the processing of travel request. Then, ideas for improving the App would come out, such as “Is it good enough that all that Boss does is just to look over the request?” For the final round of this tutorial, I will introduce you the implementation of “Split” which changes the token destination according to the conditions. This would greatly enhance the expressiveness of the App.

Making the Boss being able to “Reject” the request

In the state now, a travel request cannot be rejected. The Boss should be able to choose whether to “approve” or “reject” a request after reading its content at the “Approve” Task. Let’s create this option of “reject”.

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 “Approve” Task toward it.

When you added a flow arrow, indications of “Condition 1” and “Condition 2” appear on the diagram. Those will be the name of the buttons to be displayed at the bottom of the Task Operating form. In other words, it represents a Split which the destination of the token changes depending on which of the “Condition 1” and “Condition 2” buttons are selected on the form.

Setting up the name of buttons

Now, let’s set the display labels of each button. Double-click on the “Approve” Task icon to open the properties window. When you move to the “Split” tab, you see the setting item for button name, there.

Modify the name of the button whose Destination is “Confirm” to “Approve”. Likewise, change to “Reject” for the one whose destination is “End”. By doing this, it has become that when the Boss finishes handling of the “Approve” Task by clicking on the “Approve” button, the token will transit to the “Confirm” Task, and by clicking the “Reject” button, it will go to the “End Event” on “Boss” Swimlane. Now, save the App and release it.

If “Canarias” requests for travel, for example, and “Sumatera”, who is the Boss of “Canarias”, opens the Operating screen of “Approve” Task, it will be like the above figure. Try clicking on the newly created “Reject” button.

The token advanced to the End Event on “Boss” Swimlane and the Process has been ended. In this way, you can change the transition destination of the token by using the option. This is one way of implementing “Split”.

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

Letting the company president check in cases of requests with high-priced costs

Finally, let’s make the App so that requires confirmation on requests for expensive business trips that will cost more than 10 thousand dollars, also by the president of the company. Please start up the Modeler, as we are going to revise the App again.

Editing Workflow diagram

First, modify the Workflow diagram as follows. We will newly add the “President” Swimlane and make substantial changes after the “Approve” Task. Let’s see the procedure in detail.

First, add a Swimlane, “President”. Put a new Swimlane in between “Boss” and “Management department” by drag and drop. Then, change its name to “President”. Also, add a Task to “President” Swimlane and name it “Confirm”.

The green diamonds labeled “Split”, “Merge” in the above figure are referred to as Gateway. They control the Splitting and merging of flows. The Gateway is contained in the “advanced” palette, not in the “basic” palette which contains human tasks and so on.

When you hover the cursor over the diamond icon, the list of Gateways is expanded. You can add various Gateways to a Workflow diagram by drag and drop the icon. The following two Gateways are used this time.

Exclusive (XOR) Gateway Advance to the one which satisfies the condition first among multiple flows
Join Gateway Merge multiple Split flows into one

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

It is correct if the Objects are arranged as above figure.

All we have to do is to redraw the flow arrows. Upon doing so, please be careful not to carelessly move the flow extending from the “Approve” Task of “Boss” Swimlane. To the flows of “Reject” and “Approve”, the Splitting condition set earlier is given. Since deleting or rerouting the root of the flow (“Approve” Task side) will delete the Split condition setting, so you will have to set it again. Especially, please do not delete and redraw the “Approve” flow. Drag and drop the arrowhead of the flow.

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

After redrawing all the flow arrows, check if the name of the flow extending from the “Approve” Task remains as “Reject” and “Approve”. Once the flow arrow is deleted or its root is removed from the “Approve” Task, the Splitting condition is deleted, and the indication returns back to “Condition 1” and “Condition 2”. If that happens, please re-establish the Splitting condition you set in “Making the Boss being able to “Reject” the request”.

Setting the Split condition

Next, set up the Splitting you arranged newly. Open the property window of the Exclusive (XOR) Gateway. There, you can set the transition destination of the token by each condition at the “Determination of the destination” section.

Condition Destination
Travel cost is more than 10 thousand dollars “Confirm” Task on “President” Swimlane
Others “Merge” Gateway on “Management department” Swimlane

It seems that the App will behave as I desired if I can set up as the above table. As there are two conditions and a “Default flow” from the beginning, so let’s edit those. A Default flow is what to be selected when none of the transition conditions is satisfied. Thus, it will be sufficient if you set the condition “Amount is over 10 thousand dollars” and a Default flow. The default flow will play the role for “Others” of the above table.

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

And in another condition whose destination is “Confirm”, the Conditional Expression has been set as “Always move to Destination”. You will change it so that “move to the destination if the amount is greater than or equal to 10 thousand dollars”. Click on the Conditional Expression to open the setting window, and set up as the following.

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

Please confirm if the property of “Split” is as the above figure. There is nothing to set in “Merge” (Join Gateway). Now, you have completed the Workflow diagram!

Setting Operator

After finishing editing the Workflow diagram, you will set up Operators next. On the Operator tab, change the Operator of “President” Swimlane to “Organization”, “00 COMPANY NAME”, “Leaders who belong to this”. Since the top organization of the company is “00 COMPANY NAME”, so the leader of it represents the President.

Now, save and release it, and try making a request with a price of more than 10 thousand dollars as an employee. First, like before, “Approve” Task will be delivered to the immediate Boss. When the Boss “Approves” it, the “Confirm” Task will be delivered to “YOU”, who is the President of the company.

Does the App you created works properly? Once you created the App, it automatically processes the designation of the immediate Boss, and whether the president to confirm or not. And the logs of who operated which Task and when can be confirmed anytime later.

This is the end of Tutorial for beginners of Questetra BPM Suite. I introduced only the rudimentary content of the functions of Questetra BPM Suite, but how was it? I hope you will make your challenges for automation and visualization on business rules which are iterated every day with 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: