Robot registration and work groups

Every unattended robotic process automation (RPA) robot must successfully register with Pega Robot Manager™ before the RPA can process assignments. The robot requires a registration operator ID to register a robot for unattended RPA. During the robot registration process, the system creates an operator ID for Pega Robot Runtime, if one does not already exist. The registration operator ID may be used for more than one robot, and the ID is also required to associate the robot to a work group to determine which assignment types to process. The provisioning of Pega Robot Runtime to its default work group is performed once the robot registers successfully.

The system uses two parameters to determine the robot run-time default workgroup: the Dynamic System Settings (DSS) WorkgroupSpecifiedInPayloadTakesPrecedence, and the type of robot. The two robot types are RPA service-assisted or standalone. The WorkgroupSpecifiedinPayloadTakesPrecedence DSS alerts the system to either use the value configured in the commonconfig.xml file or the configuration of the decision tables to determine the robot's default work group.

Users must configure three decision tables to provision the default work group for Pega Robot Runtime. For access to maintain and edit the necessary decision tables, the Pega Robot Manager portal provides an user-friendly user interface to implement any changes. The images below first show the decision table in Dev Studio and then its counterpart in the Pega Robot Manager portal.

• The pyGetWorkGroupbyRobotID decision table allows the robots to register to their base work groups based on robot ID. If the robot implementation is to use a robot registration operator ID, you must clear the values in this table. The Work group and robot mapping section in Pega Robot Manager references this table. 

   

  
  

When you create new work groups in Pega Robot Manager, you must configure a decision table that defines the association of the new work group and assignment types for proper routing of the assignments.

• The pyGetWorkGroupForRobotByRequestorOperatorID decision table allows the robots to register to their base work groups based on their windows identity. If different robot registration operator IDs are used to provision the correct work group, you must complete the values in this table for each different robot registration operator ID and matching work group. The Work group and requestor mapping section in Pega Robot Manager references this table.

   

  
  

• The pyGetAccessGroupForRobotByWorkGroup decision table sets the robot's access group based on the robot's base work group registered from the pyGetWorkGroupForRobotByRequestorOperatorID. The Access group and work group mapping section in Pega Robot Manager references this table.

   

  
  

By providing access to the robot registration and provisioning decision tables In Pega Robot Manager, the same Enterprise Class Structure (ECS) methodology still applies and is managed through the Pega Robot Manager portal.

By default, when a new Pega Robot Manager application is created with the New Application wizard, decision tables and notification threshold settings are created automatically for that application instance. When subsequent Pega Robot Manager applications are built through the ECS, the decision tables and notification threshold settings may be inherited from the built-on (parent) application. If an application does not contain its own instance of the settings, the application inherits the settings from its parent application, following the application stack until the dependency is resolved. The application defaults to the Pega Robot Manager instance for the settings if no inheritance or application stack exists.

Consider an organization that has various unattended RPA robots across different divisions or units. One area has a small number of robots, while another area has a larger number of robots. Managing how the robots are registered, provisioned, or shared may vary because the number of robots. Through the Pega Robot Manager portal, you can create specific instance decision table and notification threshold settings or set them to inherit the values from its parent's application. Having this flexibility at the table and setting level allows the administrator to determine how to manage how robots are implemented across an organization.

Because of application inheritance, when you change a decision table or setting value in a parent application, the change is reflected in the child applications that do not have their instance of the decision table or setting.