When integrating robotics into your Intelligent Automationsolution, you should carefully consider the right type of robot to use – attended or unattended. These are important considerations for architecting your overall solution because using the wrong type of robot can have a negative impact on the overall deployment. If a Pega Customer Service user is waiting too long for data to return from an unattended robot, or the Pega Customer Service user is having to wait too long for an attended robot to finish, it could lead to reduced satisfaction for the overall Pega implementation.

Ways to invoke an attended robot

1. Pre/post processing flow actionstep

   • Easily falls into the Pega application UI screens.

   • Has a 60-second time-out, which is the maximum reasonable amount of time to expect an attended user to wait.

2. Data page

   • Separates data access from the application rules, for a better overall design.

   • Has the ability to enter a custom time-out and this can be abused by developers and create an environment that is not realistic for a Runtime user.

Ways to invoke an unattended robot

1. Using the unattended robotic smart shape

   • Embeds the data access within a Pega application

2. Data page

   • Allows for a modular approach to the Pega application.

   • Note that this uses a one-stage, one-step case flow within the Robot Manager application.

Considerations for choosing between an attended or unattended robot

Is the automation collecting data that is needed in real-time or writing data to a legacy system?

If the automation collects data that is needed in real-time, then attended robots are best for the use case.The attended robot is always there for the user and no queueing (on Robot Manager) is involved.

If the automation writes data to a legacy system, consider an unattended robot. This allows the legacy application to be updated without slowing down the Runtime user. If the unattended robot should raise exceptions while processing, create a Pega work flow that allows the exceptions to be handled at another time.

How long does the automation take? Is the user of the automation working directly with a customer?

If the automation takes a long time to complete (60 seconds or more), then it is not a good practice to ask an attended Runtime user to sit by and wait for the automation to be done. Consider breaking up this automation or sending it to an unattended robot.

Can the applications be automated in the background?

In other words, what automation techniques need to be used? Are SendKeys/OCR involved that will take the mouse or keyboard away from the user?

If the application can be performed in the background using Deep Robotics methods only, and does not require any OCR or SendKeys calls, then this is a great attended use case. If OCR and SendKeys are required, consider doing this as an unattended automation.

Rethinking work flows to minimize any negative impact to the attended user

• Navigate applications to screens that may be needed as the call begins. For example, search for customer in all applications at the beginning of the call, even if you do not know that the application will be needed during the call.

• Avoid one monolithic attended automation that takes too long. Separate it into multiple automations that are invoked from various steps within the Pega application. Here is an example:

  • Automation 1: Open the application and navigate to the customer information at the start of the call.

  • Automation 2: Retrieve the current customer information available for user to see as the Runtime user determines why the customer has called.

  • Automation 3: Update the legacy applications with data received from the customer.

• If user input is required during the attended automation, it should be entered through a user interface in the Pega application and not through data entry forms created using Robot Studio or the applications being automated. By returning control to the Pega application, the timing for the data entry will not fall under the 60-second maximum.