Custom case issue resolutions

As an administrators, you must understand how you can use your organization’s issue resolution process to route unsuccessful cases to the appropriate party for case completion. For example, these routing failures might occur due to an automation error. Pega Robot Manager™ provides a link to case details for each issue on the Issues tab to allow for further investigation and processing.

Pega Robot Manager has out-of-the-box (OOTB) default actions to resolve issues. Still, it is a best practice that the organization customizes these actions to meet its different business needs. Depending on the issue resolution process defined by the organization, along with the specialization implemented on the portal Issues, Actions, and Case Details page, it is recommended that administrators understand and follow the defined process. For example, an administrator that is troubleshooting a Failure on the Issues page cannot access a failed automation, or strict instructions state that administrators must contact a specific party for assistance depending on the organization’s procedure.

The ability to customize changes allows you to adjust functionality to meet both the administrator and organization demands. Once updates are made to the functionality, you can have either more or fewer actions available to resolve cases. Designated parties within the organization must also correctly configure the operators and work queues to continue case processing.

When an application is generated to use with Pega Robot Manager, standard flow actions and subflows are created in the case. The robotic solution status helps you manage and monitor work that is processing as well as the robot's and package’s assignments in Pega Robot Manager. It is important to understand how the systems use these statuses when an automation issue is flagged in Pega Robot Manager. When an unattended robot runs an automation by using the OOTB pyCompleteAutomation flow action, Pega Robot Studio returns one of the following statuses:

• Completed
• CompletedWithErrors
• DidNotComplete

In addition to the case status, data from the automation can be passed from the automation to the case for validation by using customized validation rules. For example, a platform mortgage application is connected to an automation that calculates the risk assessment value for a borrower and returns that value. The risk assessment number returned from the automation is passed back to the case. Once the case receives that value, a validation rule can then be applied to the case. The assignments that fail that validation are displayed under the Conflicts tab. Possible validation and status scenarios include:

• If validation passes and the automation status is set to Completed, flow processing continues.
• If validation passes and the automation status is set to Completed with errors or Did not complete, the pyRepairAutomation subflow runs in the Robot Queue process step of the case life cycle. This subflow, by default, has an assignment called Repair Automation, which can be manually moved forward or configured to re-run. You can also customize the pyRepairAutomation subflow to fit your business needs.
• If validation fails, the assignment is returned to the work queue from which it was obtained and can be processed by the robot again. By default, the case is retried; however, the failed validation can be customized as well per the business needs.

When business needs change, and more specific information is necessary, authorized users can modify the pyCompleteAutomation flow action to customize the returned status display text to show a more specific message. Within Pega Platform, the Assign to Robot Queue step in a process gives administrators the granular control to define case statuses for all scenarios a case may encounter.

During the case life cycle, designated parties within a case can be assigned various tasks to complete until the case is ultimately resolved. Typically, these tasks are assignments that are delegated to either a human or a robot for completion. On the Robot Queue process step in the case life cycle, a custom label can be set for the case status and configured for five predefined assignment states:

• Assignment is queued
• Robotic Automation is in progress
• Robotic Automation has conflicting results
• Robotic Automation fails
• Robot Automation times out