Pega Robot Runtime Work Group provisioning
Provisioning is when you successfully register an unattended Robotic Process Automation (RPA) robot and assign it to a work group. Robot Manager considers the Dynamic System Setting (DSS) and the robot type when it determines a robot's default work group. For either an attended or unattended robot, two possible processes can occur for work group provisioning: RPA Service-assisted, and Stand-alone. The processes, described below, reference the decision tables in Dev Studio:
- You use RPA Service-assisted provisioning to monitor and control robots from the Robot Manager interface by utilizing the RPA Service, which is a Windows service that must be installed on the Pega Robot Runtime machine. When an RPA Service-assisted robot starts and registers, the robot is provisioned within the defined work group. For more information on provisioning an RPA Service-assisted work group, see RPA Service-assisted robots registration.
- Stand-alone robot provisioning is when an organization does not use the Pega RPA Service or communicate with Robot Manager to control its robots. When taking this approach, administrators need to manually access the robot to start, stop, terminate, or schedule robots.
Work group and access group provisioning
When you create new work groups in Robot Manager, you must configure a decision table that defines the association of the new work group and assignment types, in order to route the assignments properly. For example, as an administrator you want Robot Manager to automatically assign each robot to a work group, so you customize one of the provided decision tables. Users must configure three decision tables to set the default work group for Pega Robot Runtime. To make it easier to maintain and edit the necessary decision tables, the Robot Manager portal provides a user-friendly interface to implement any changes.
With the pyGetWorkGroupbyRobotID decision table, robots can register to their base work groups based on robot ID. If the robot implementation uses a robot registration operator ID, you must clear the values in this table.
In the center of the following image, slide the vertical line to view the pyGetWorkGroupbyRobotID decision table in Dev Studio, and the corresponding Work group and robot mapping section in the Robot Manager portal:
With the pyGetWorkGroupForRobotByRequestorOperatorID decision table, robots can register with their base work groups based on their windows identity. For example, you can use different robot registration operator IDs to provision the correct work group. In that case, you must complete the values in the pyGetWorkGroupForRobotByRequestorOperatorID decision table for each distinct robot registration operator ID and matching work group.
In the center of the following image, slide the vertical line to view the decision table in Dev Studio, and the corresponding Work group and requestor mapping section in Robot Manager:
The pyGetAccessGroupForRobotByWorkGroup decision table sets the robot's access group based on the robot's base work group, registered from the pyGetWorkGroupForRobotByRequestorOperatorID.
In the center of the following image, slide the vertical line to view the pyGetAccessGroupForRobotByWorkGroup decision table in Dev Studio, and the corresponding Access group and work group mapping section in Robot Manager:
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?