8. Routing Algorithm

While this definition is for sending data packages over the internet, is can also be used for dynamic case management. For DCM, you want to route your cases (network traffic) to different knowledge workers (selected paths). In other words, while many knowledge workers are eligible to perform a task, a routing algorithm selects the one who is actually assigned to perform the task. Just as with an 6. Authorization Algorithm, Blueriq uses a role-based approach here.

When modeling your application, you want to indicate that a task should be assigned to certain roles, teams or users. Here are three practical examples which we will use throughout this document to show the ideas behind routing. (1) A bank gives out loans to customers. You want that the task of approving loans is done by an employee from the Customer_Loan department. The managers also are authorized to execute this task, but this is only done for special customers or in emergency situations. Therefore, you want that all loan approval tasks are routed towards the Customer_Loan department by default. (2) The bank operates on the national level, and you want that customers in the north of the Netherlands are routed towards Team Amsterdam, while customers in the south of the Netherlands are routed towards Team Maastricht. (3) A customer with a long history with the bank applies for a new loan. You want to assign the Loan_Approval task to the employee who is already familiar with the history of this customer.

Roles, Teams and Users

We have 3 different concepts available to fulfill our Dynamic Case Management needs: Roles, Teams and Users.

Roles: A role describes a set of people which fulfill the same tasks within the organization. People with the same role can be distributed amongst different teams.

Teams: A team is a set of people who are linked to each other by some feature, for example the location. People in the same team can have many different roles.

User: A user is a single individual. This user can have of 0 or more roles and be part of 0 or more teams.

In this example, the three concepts above are visualized. The organization has 3 members of the Customer_Loan department, 2 in Team Amsterdam, and 1 in Team Maastricht. The upper management comprises 3 people, but because they are located in the headquarters building in Eindhoven, and are usually not involved in daily tasks, we have decided to not assign a team to them. We have named 2 individual users in this illustration, Alice and Bob. Alice is a specific Manager, while Bob is member of the Customer_Loan department in Team_Maastricht.

Modeling Routing in Blueriq

The routing algorithm is responsible for assigning a Role, Team and/or User to a task. Currently, all routing is done using an external algorithm, and therefore it does not make sense to distinguish between a static or dynamic algorithm.

Modeling a routing algorithm is very similar to modeling a 6. Authorization Algorithm. We start by modeling the Teams and Roles that we need.

Now you create a new routing algorithm. The runtime is going to look for a custom implementation of the routing algorithm API in the aquima.home/lib/ folder. You can find information on how to implement this here: APIs for authorization, routing and priority. On every domain change, this routing algorithm will be executed and it should result in either a combination of Team and Role, or User. When the algorithm does not set any of these values, then the tasks is available for everyone.

For example (1), the algorithm can always return 'Customer_Loan_Department' as assigned Role. For example (2) the algorithm also returns 'Customer_Loan department' for Role, but it also returns a Team based on the geographical location of the client. If it is closer to Amsterdam, it should return 'Amsterdam', and 'Maastricht' otherwise.

Now the only thing left to do is decide which tasks should be routed by the newly defined algorithm.

When modeling your worklist, there is the option 'Show all tasks'. When this option is disabled, a knowledge worker will only see the tasks assigned to him. 'Assigned to him' can mean that a task is assigned to him as a person specifically, or to his Team/Role combination.

Manually assigning a task to a specific user

While an algorithm can do a general assignment automatically, the customer might still want you to model a page on which he can make manual assignments. This is possible with the use of the AQ_AssignTask service:

With this service, you overwrite the default assignee of the routing algorithm. In this example, assigned.users, assigned.teams and assigned.roles are multivalued string attributes.You can use this service in two ways: (1) to assign a user to the active task, or (2) assign a team or role (combination) to the active task. When using this service, you have to pay special attention to unknown values. For example, you assign a team and a role, and the team attribute has the value of system-set unknown, the team will not be set. If, however, the team attribute is user-set unknown, the task will be routed to the "" team.

You would normally show a page on which a user can decide to who an (active) task should be routed to. The most common flow for doing this is as follows: You leave the worklist, using a 'Show Task Details Button'. With the AQ_GetTaskInfo service you retrieve task information for the chosen (active) task. The user can press a 'Reassign' button which leads to the 'Reassign' page, shown here on the left. On this page you present different routing options for User/Team/Role. Here you ask the user what he would like to to assign, a user, team or role. Model an 'Assign' button which leads to this service. Depending on what the user would like to assign, a different service is reached. This flow is shown to the left. Example (3) can be achieved with this solution.

Who can see a task?

Wether a user is able to see a task in his worklist, is based on some rules. These are in short:

• A user can see a task in the worklist if it is directly assigned to him.
• A user can see a task if it is routed to a set of Roles and a set of Teams and the user has at least 1 assigned Role and 1 assigned Team.
• A user can see a task if it is routed to a set of Teams and the user is part of one of these Teams.
• A user can see a task if it is routed to a set of Roles and the user has one of those Roles.
• A task has no assigned Role/Team/User.

These rules are executed from top to bottom. To make things clearer, here is an extensive table of examples of how this mechanism works.

User=([Name],[Teams],[Roles]), for example: ([Bob],[west],[admin,sales]) indicates that a user Bob is part of team "west", and has roles "admin" and "sales"

                                                  for example: ([Alice], [south],[sales]) indicates that a user Alice is part of team "south", and has role "sales"  

Task=([UserNames][Teams],[Roles]), for example: ([], [north,south],[management]) indicates that a task is routed to team "north" and "south" and to the role management.                                                           for example: ([Alice], [],[]) indicates that a task is routed to Alice.

[ ] is possible and means that the routing algorithm did not make an assignment. This means that everyone can do it.

An X in the table blow indicates that the user to the left can see the task to the top, for which the routing algorithm was used.

Logging in

The basics for logging in are already described in the tutorial for the 6. Authorization Algorithm. There you have learned how to assign roles to a user. With routing, we have one additional concept, the Team. The Team(s) of a user cannot be set using a settings file or via the LDAP. It is therefore up to every individual project to fill the system.user.teams attribute when the user logs in, using custom made code.