Application Queue
In the Application Queue we can see the following:
- Applications received that day.
- Number of applications in the queue.
- Applications assigned to the users.
- The number of unassigned applications.
All the applications with their necessary details can be viewed in this section. An application can be easily searched using the application ID or applicant's name. The applications can also be sorted and filtered (by branch, application timestamp, application type, assignment status, and assigned user) for easy navigation. Application(s) can also be assigned/reassigned in this section.
Filters applied to the screen can also be saved so that back office user(s) can easily navigate and quickly access the applications using the saved filters. (maximum 5 filters can be saved and managed).
- Apply the required filter(s).
- Enter a name for the filter that is to be saved.
- Click on the 'Save Filter' button.
This filter can then be used whenever required by selecting the saved filter from the 'Filter View' dropdown.
- Click on the 'Filter View' dropdown.
- Select the 'Manage Filters' option.
- Here the saved filter(s) can be renamed/deleted.
- Click on 'Delete' for the filter that has to be deleted.
- Click on the ✅ symbol.
- If the filter has to be renamed, click on 'Rename'.
- Enter the new name.
- Click on the ✅ symbol.
The strategy based on which the application flows into the back office after successful submission will be assigned to the application auditors (back office users). Currently, GO supports 4 types of assignment strategies:
- Random: If the assignment strategy is set to 'Random', applications are randomly assigned to back office users.
- Fields: If the assignment strategy is set to 'Fields', applications are assigned based on values returned by certain field(s) from the front end. E.g.- Consider a merchant account onboarding use case. A merchant is categorized as a high, medium, or low risk depending on the kind of business s/he is into. If the merchant is in a business that is categorized as high risk (e.g.pawn shops, jewelry stores, antique businesses, etc), the application needs to undergo an audit by a risk team person. In this case, the assignment happens based on the risk assessment field present at the front end of the applicant's journey.
- Performance (Deprecated): If the assignment strategy is set to 'Performance', applications are assigned based on the performance of the back office user.
- Round Robin: If the assignment strategy is set to 'Round Robin', applications are assigned on a round-robin strategy. In the round-robin strategy of allocation, the following steps are followed:
- Back office users with the most and least number of applications are identified.
- The user with the least number of applications is then allotted until his/her count reaches the user with the highest number of application allocations.
- Post this, the applications are allotted to users on a round-robin basis (one to A and next to B). Once all the back office users have an equal number of applications in their buckets, applications flow into their buckets one by one in equal order.
The 'Pooling and Assign to me' feature allows users in the back office system to create multilevel roles, assign users to those roles, and submit applications for review and escalation. The feature follows a hierarchical structure where managers have higher authority than employees.
Step 1: Create Multilevel Roles
- Create two roles: Manager and Employee.
- Set the Manager role as the top hierarchy as Level 1 and the Employee role as Level 2.
Step 2: Create Users with Roles
- Create users with Manager and Employee roles.
- Assign one user as the Pool User for the Manager role and another user for the Employee Pool.
- Create additional users for testing purposes, such as Employee_User1, Manager_Pool, and Manager_User1.
Step 3: API Call to Set Lowest Level User
- Use the provided cURL API call to set the lowest-level user.
- Replace the API endpoint, application ID, and user ID with the appropriate values.
- Make a PATCH request with the Authorization header and the JSON payload.
- Set the 'lowestLevel' to false for all users except the lowest level user.
- Execute the API call individually to set the 'lowestLevel' flag to true for the lowest level user (Employee_Pool).
Step 4: Create Application
- Use the Create Merchant API to create a new application.
- Select the desired branch for the application.
- Submit the application.
Step 5: Assign and Escalate Application
- Log in to the back office system as Employee_User.
- Assign the submitted application to themselves.
- Escalate the application to the Manager level.
- The application will be escalated to Manager_Pool.
- Log in to the back office system as Manager_User1.
- Accept or take the desired action for the escalated application.
Note: The concept of pooling is commonly used in banking, where multiple officers review applications and escalate them to higher authorities for further verification and final decision-making.
- Click on the 'Assign/Reassign' button present on the left side of each application.
- Select the search category (e.g. Name, Employee Code etc.)
- Search the name of the person to whom the assignment/reassignment of the application has to be done.
- Click on 'OK'.
The contents of "search by" dropdown can be realm-wise configured from admin portal
In Backops tab, settings > Application Queue Configuration
Getting help
Please feel free to contact us if you have any questions, require clarification, or have ideas for how to make the documents or any of our services better.
You can reach out to us at [email protected].