Failed assignment resolutions
Administrators require familiarity with the issue resolution process of an organization to route unsuccessful assignments to the appropriate party to complete Cases. With Pega Robot Manager™, you can customize functionality to meet the administrator and organization's issue resolution needs, for example, by adding or removing actions to help resolve Cases.
Note: Communicate these updates to all designated parties in the organization so that users can configure any operators and Assignment types to maintain Case processing.
Although Robot Manager includes default actions to resolve issues, you can implement customization during the Case design process and development stages to suit your organization's resolution needs. You can implement these customizations to the menu, the Issues tab, and the Case details to assist you in following the resolution process defined by their organization. For example, you are troubleshooting an Automation failure from the Issues page and cannot directly access the failed automation. Robot Manager provides a link to Case details for each issue on the Automation failures tab to allow for further investigation, but you want to consider specific instructions regarding handling any problems from your organization. The following figure shows how you can click the link on the Issues tab to open the Case details to view the options available based on your organization's rules and permissions in Robot Manager:
Case issue resolution
In addition to understanding the issue resolution process of your organization, it is also beneficial to understand Case statuses and data validation. The Case status reflects any Automation processing failures in Pega Platform™ first. After you define a Case status, you have granular control over any problem that a Case can encounter. On the Robot Queue process Step in the Case Life Cycle, you can set a custom label for the Case status, and then configure it for one of five predefined Assignment states. For more information about assigning a Case status, see Assign to Robot Queue.
In addition to the Case status, the automation passes data to the Case for validation by using customized validation rules. For example, a Pega Platform mortgage application connects to an Automation that calculates the risk assessment value for a borrower and returns that value. The Automation passes the risk assessment number back to the Case. When the Case receives that value, the system can apply a validation Rule to the Case. Examples of validation and status scenarios include:
- Flow processing continues if validation passes and the automation status is Completed.
- If the validation outcome does not have a Completed or Completed with errors status, the Task goes to the Automation failures list by using the pyRepairAutomation flow.
- If the validation fails or the outcome results in the Completed with errors status, the Task goes to the Conflicts list by using the pyRouteAutomationToConflicts flow.
Note: Both flows are customizable by clients.
Handling underperforming robots
As part of the issue resolution process, Robot Manager continuously monitors failed Assignments over a period to stop underperforming robots. By identifying and stopping robots that fail their Assignments too often, administrators can decide how best to resolve the issues based on their organization's process. Case resolution can mean removing failed assignments or routing unsuccessful ones to the appropriate party.
Robot Manager sends warning messages about robots that are approaching failure thresholds. By attending to and understanding these messages, you can address failing robots before Robot Manager stops them automatically. Robot Manager evaluates robot performance by monitoring the following failure threshold settings at the Work Group level:
- Consecutive failures threshold: The number of consecutive failed assignments within the alert evaluation time.
- Failed automations threshold: The percentage of failed assignments within the alert evaluation time.
- Not ready threshold: The duration that a robot can remain in the APPLICATION NOT READY state, set by the Automation and run by the robot, until Robot Manager considers that robot to be underperforming.
For more information about failure thresholds, see Configuring robot failure tolerance.
When any robot exceeds a failure threshold, Robot Manager considers the robot to be underperforming for that Work Group and stops it. The following table describes specific scenarios that can occur depending on your robot configuration:
|
Configuration |
Scenario |
|---|---|
|
The robot already has an established schedule |
Robot Manager starts the robot again, following its original schedule. If the situation persists, Robot Manager stops the robot again but does not restart the robot according to the original schedule. |
|
The Work Group has Auto-balancing enabled |
The root cause of the robot's repeated failure might only apply to the current Work Group. If Robot Manager considers the robot to be underperforming, it stops the robot but can move it to another Work Group. |
|
Robots are controlled manually |
The robot remains in Standby until a user manually starts the robot again. |
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?