Queue Management
This document explains the implementation of queues for applications and tasks based on configurable assignment and escalation rules for back office bank user to handle applications and tasks effectively.
Overview
Queue management functionality provides the infrastructure to automatically segregate and assign applications or tasks under specific queue buckets. The feature has out-of-the-box assignment and escalation rules for Retail, SME application and task queues and the documents are enclosed for reference purpose.
Download the Retail, SME application and task queues as required (compressed file in .zip format).
A bank staff administrator can define assignment rules and escalation rules based on which the object types such as applications or tasks are assigned to the queues defined by the administrator.
The submitted applications (requests) are assigned to various queues until a signed-in user with access to the queue claims the application. After the application is claimed, corresponding tasks are created and placed in the queues where a signed-in bank user with access to the queue claims the task. After claiming, the application or task moves out of the queue and is available on the My Requests or My Tasks tab of the user who claimed the request or task. Instead, when an object (task) is released by a user (who claimed the object or by his/her supervisor), the object moves out of the user’s individual worklist (My Tasks) and moves into a queue based on the assignment rules defined by the bank staff administrator - the system applies the same assignment rules to a task that is being released as to a task being created afresh before assigning it to a queue. The bank staff administrator can also define the users or user groups who will have access to view these queues and the objects in these queues.
A supervisor can view the complete audit trail for each object present in the queues to which the supervisor has access. The audit trail includes details of the date and time the object entered a queue and the date and time the object moved out of the queue (through claim/release/reassign/any other manual or system action) until the object reaches a terminal stage - Completed, Canceled, or Withdrawn (for applications/requests).
Additional notes
- Different Queues can be defined based on various attributes and DMN rules.
- Out-of-the-box, different queues are defined at application and task levels, and journey wise band (onboarding or lending, product wise, region wise) for tracking tasks pending overdue as per SLA for each task.
- Application/Tasks are automatically assigned to respective configured queue.
- Users can be granted required permissions to various queues and based on the access to the queue, can claim application, and work on the application.
- Post submission, the application is automatically assigned to the respective queue based on the queue criteria.
Functional Flow
Applications
- After the applications are migrated to Origination Processing microservice, the application is assigned to a queue based on the rules configured in Red Hat PAM.
- The list of queues are displayed based on the queues attached to the user’s profile in Keycloak.
- A user can view the list of unclaimed applications present in a queue and claim any application in the list to move it out of the queue and into the user’s applications.
- A supervisor user can move the applications between users at any point.
Tasks
- Before any task is created, the group assigned is decided based on the rules configured in Red Hat PAM.
- Team Tasks are displayed based on the queues attached to the supervisor’s profile in Keycloak.
- A user can claim any task to move it to My Tasks section.
- A user can release the task at any point to move it back to the queue for other users who have access to claim the task.
- A supervisor can release or reassign tasks between users at any point in time until completion or cancellation.
Technical Flow
Applications
- The assignment rules are triggered as part of the post submission process as in-progress applications are not supported. The resultant queue name is updated to the relationshipManager field in Request entity of Origination Processing microservice.
- When a user logs in, My Queues displays all the queue names the user is part of in Keycloak.
- On clicking a specific queue, Origination Processing microservice is queried to return list of requests having the queueName as relationship manager.
- On claiming an application, relationshipManager is updated with the username of the user claiming the application.
- Reassigning the applications update the relationshipMananger with the new username selected by the supervisor.
- Audit logs can be constructed using history tables in Origination Processing microservice.
Tasks
- Before any task is created, a DMN is invoked with necessary details to decide the assignment queue.
- For escalating tasks, Fabric jobs are configured to run daily at a given time to evaluate all overdue tasks and reassign the queues based on the escalation rules configured.
- Audit logs are stored by Red Hat PAM and is available in business central and uses REST APIs.
Experience API
Integration Service
- Operation: EvaluateTasksOperation
- Integration service name: OriginationJavaServices
- Description: Service to fetch all tasks and invoke assignment rules and update task assignee/group if required.
Object Service
- Object service: Origination Processing microservice
- Object: Task
- Verb: getTasksForQueue
- Description: Service to fetch all tasks for a given queue name
-
Request - Response
Configuring Scheduler for Overdue Tasks
This section corresponds to the escalation rules defined for overdue tasks as escalation jobs in Fabric console.
To configure task escalation Fabric job, follow these steps:
- Open Job in Fabric admin console.
- Click Add New.
- Configure the job as shown in the image above on the Job Info tab.
- Define the required schedule for the job on the Schedule tab.
- Click Save & Schedule.
In this topic