By creating operators you provide access for users and processes to your application so that processing work can happen, and so that business processes can reach successful resolution. You can create operators not only for users, but also for automated, unattended processes. Unattended operators are robotic automation virtual machines (VMs). The system generates unattended operators for each registered VM in a robotic process automation (RPA) solution. Creating unattended operators increases the automation of your business processes, lowers costs, and speeds up work resolution.
Creating operators gives you the following benefits:
- Increased security
- Every operator can have a unique password with which to log in to your application. As a result, you protect your data and operations from inappropriate or random users.
- Improved routing of work
- Every operator has an individual queue of assignments to complete that Pega Platform refers to as a worklist. Additionally, you can give an operator access to a work queue that groups assignments that are available for members of a specific team. For every operator, you can specify the level of relevant skills, for example, you can indicate that an operator is a highly advanced Java developer, or speaks French fluently. Grouping assignments and defining skillsets improves the routing of work and ensures that an application assigns tasks to the most appropriate users. For every operator, you can also define periods of unavailability and a substitute worker or work queue to ensure continuous case processing.
- Relevant access type
- You can define which data and operations an operator can access and perform in your application. For example, you can ensure that only a manager can approve or reject new job candidates, or that a CSR can access all information that a case requires to reach resolution. Consequently, the users of your application can perform only relevant actions and process their work faster.
The following figure summarizes the options that are available for operators in Pega Platform applications:
Clusters and operator IDs
After you save a new, or update an existing operator ID instance, the change might not be reflected on another node in a cluster until the Pega-RULES agent on that node performs the next system pulse — typically after no more than 60 seconds. Unlike instances of most other Data- classes, the system saves operator ID instances to the rule cache. As a result, until the next time that the rule cache is synchronized, one node might access a stale copy from its rules cache.
Bulk operator load
To save time, you can create operator ID instances by importing a comma-separated values (CSV) file, such as a Microsoft Excel spreadsheet.
Operator ID property
After a requestor logs in, the operator ID identifier is available on the pxRequestor page as the pxUserIdentifier property.
Operator IDs and external identity providers
If you implement authentication by using an external identity provider (IdP), the login process accesses IdP for authentication and ignores the password in this operator ID instance. However, the system still requires an operator ID data instance for each user.
The system saves passwords for operator IDs as hashed values in the PegaRULES database, by first salting the clear text password value and then hashing it using the default bcrypt algorithm. The system uses two property types when changing the password: Password type for the New Password field, and Text type for the Confirm Password field. The Data-Admin-Operator-ID.pyPwdCurrent property stores the hashed password after the password passes validation.