Method for Implementation of Approval Route in Complex Organizational Hierarchy Using Role

Hellow, everyone.

I have introduced you the way how to implement

  1. Easy to understand the approval route。
  2. Process Models to be less likely to be affected by organizational change

in the article of “Method for Operator Setting Being out of Process Model”, the other day.

<Method for Operator Setting Being out of Process Model>
* Complexity of Process Model
* Problem upon organizational change (Revising will be required in many Process Models.)
You are able to correspond abpve problems by the following measures.
* To determine the approval route in each organization in advance
* To store the approval route information outside the Process Model (Options XML)

Today, I would like to introduce you a method which I have mentioned in “Afterwords”.

In fact, there is a similar way of implementation.
It can be achieved in a more simple by the use of Roll. (I will introduce in the next and subsequent)

It will be implemented using two features below.

* Role
* Error Boundary Event

Regarding “Role”, it indicates a feature to define which User has been assigned the “Entitlements” such as “Manager”, “General Manager”, “Board of Directors”.

<Nomination by Organization and by Role>
When an Issue arrives at each Step, it will appear in [Offered] of all the candidate of underwriting. The first person who makes the underwriting processing will be the actual operator (in charge). (The Issue appears on [My Tasks] of the operator.) Candidates of underwriting will be nominated by various expressions, such as “people who belong to Sales Department” or “Leader of the Organization which the applicant belongs to”.

Regarding “Error Boundary Event”, it is configured at “Automatic processing / Error handling” in property of a Task. It will be enabled when you select the option of “Abort task (token will move to Error Boundary Event)” for “If there is no user corresponding to the operator setting“.

<Seting example of Error Boundary Event>
Error Boundary Event setting

A Process Model defined by combining features above is as the following figure.

Process Model setting

I’m going to give you a step-by-step explanation.
There are two points that you must realize.

1. Search for the approver, then allocate the approval Task.
2. Let the flow go to the approver in the next layer skipping a layer in which no approver exists.
1. Search for the approver, then allocate the approval Task.

Searcing for target user

* Set up Swimlane [Employee], – Leaders or staff memebers in the UPPER organization of – a user who operated tasks in this swimlane in Operator setting.
* Set up Role in accordance with the approval organizational hierarchy.

It will be realized by these settings.

<Setting example of Swimlane operator: Manager Role>
Setting example of Swimlane operator: Manager Role
2. Let the flow go to the approver in the next layer skipping a layer in which no approver exists.

I will explain as an example of the approval route shown in the following figure.

approval route: Organizational hierarchy

The “approval route #1” is the simplest approval route that passes every approving layer.
The sequence of the Steps in Process Model is as the following figure.

approval route #1

The “approval route #2” is an approval route in which “Manager hierarchy” does not exist.
An “Error Boundary Event” is utilized there.

approval route #2

Since the user who holds a “Manager role” does not exist in the upper from the applicant, there is no Operator on the “Manager Swimlane”.
Therefore, that Step is not executed, and it goes to the next “General manager approval” via the Error Boundary Event.

Thus, a flow, in which person who hold the authority to be able to give an approval on an application from an organization that particular hierarchy does not exist, is implemented.

(You may have recognized already though,) there still are possibilities of occurrence of a problem.

* Application through “Approval route #2”
* “General sales manager” concurrently serves as “Sales manager”

In the case above, “omitting Manager layer” is the proper route when a staff of Marketing Dept. makes an application.
However, the Sales manger (concurrently serves as Sales general manager) will be erroneously allocated to the approval Step of Manager layer, since it searches for a User who belongs to Manger Role in the upper organization of Marketing Dept.

Unfortunately, complete workaround does not exist.
But the proper approval route would be realized in most cases by enabling “Users who accepted tasks in **** are excluded” in the Operator setting of Swimlane.
* “****” indicates a Swimlane of the approval layer immediately before.


Even though there are a few “cases that cannot be helped”, I consider that it is almost usable in the reality.

This time, it is a case study of utilizing “Error boundary Event” which you may not be familiar.
I think there may be other cases where it is usable.

Please give it your consideration.


About Masato Furukubo

Questetra, Inc. Sales Department
View all posts by Masato Furukubo

Prev article - 50. Questetra Tips New Version, v11 : Try Browser Cache Clearing for Error Dialog of Modeler
Next article - 50. Questetra Tips Backup the Data of Workflow! What about Files?
Another article - Masato Furukubo How to Evaluate Questetra (Step 1)