Operator ID Usage and Configurations
In this blog article, we will Understand about the Operator ID configurations in Pega and how to create one.
This article was created using Pega '24 version.
Imagine social networking sites. They have a Sign Up link in their home page. You can sign up to create a new account. “What happens at the back end?“. A new account is created for you and it is stored in the server.
Username will be the key to link the account. So whenever you login again, the application will match your UserID and get the details related to your account.
Now, let’s come to our Pega application. As like other applications, we need a User Credentials / or a Login ID to login and access Pega application.
Because Pega is a low-code platform with different studios ( for developers) and portals (for end users), we as developers also need Login ID to login dev studio and start developing application.
Technically Login ID is called as “Operator ID”.
What is an OperatorID?
– It is a rule which comes under Organization category.
– It is a unique ID for each individual users.
– It is an instance of Data-Admin-Operator-ID. It means whenever you create a new operator ID, a new instance of class Data-Admin-Operator-ID is created.
Note: Data-Admin-Operator-ID is mapped to pr_Operators table. So whenever you create a new operator ID, you can see a new entry is made into pr_Operators table.
Don’t always think that Pega Operator ID is just User Credentials with username and password. Pega Operator ID translates to account information where you can also use external authentication like SSO to use separate entity as Identity Provider.
What are the different ways to create an Operator ID?
The Operator provisioning in Pega can be done in two simple usual ways 😉
- Manual creation
- Automatic creation.
Note: Whenever you install Pega, you get an administrator Operator ID. You can login using administrator@pega.com and configure the administration settings like setting up your system, creating your very first application and many more.
Automatic Operator Provisioning
In a Production environment, most of the time we will be using SSO for Login applications. SSO – Single Sign On. It provides a facility to log in once and access all applications securely.
Say, Your office using Microsoft Azure AD as the standard Identity Provider for all the employees. You can log in your office desktop mail using organization credentials. If SSO is enabled in Pega with Microsoft Azure AD as the Identity Provider, then you can seamlessly access Pega without using a different username and password (basic authentication)”. But of course we need to have an Operator ID / Account ID in Pega.
Via Authentication service SSO configuration, we can also create operators on the fly when they successfully authenticate against an external Identity Provider (IDP), in our example it is Microsoft Azure AD.
SSO authentication is beyond the scope of this article. I just want to let you know that OperatorID can be created via SSO authentication activities.
More about SSO authentication can be found here – https://myknowtech.com/tag/sso/
Manual creation
This is the normal case where lead developers or LSAs create new Operator IDs for the developers.
Very very rarely in a production environment, manual operator creation will be done for the end users!! It is not recommended!
Let’s start with creating a new Operator ID manually
Tip: Most of the time, you can just use a model or already created Operator ID (for example, developer from the same team) and then just do a Save-as. This will prefill most of the details and you can just update the necessary details.
Create a new operator ID from Records -> Organization -> Operator ID -> right click create new.
What are the configuration points in a Operator ID rule form?
There are 3 main tabs:
- Profile
- Work
- Security
Profile tab
Contact Information – Fill out the basic contact details of the Operator ID.
Email and Phone number can be critical for end-user operator records. For example – you may need to send notification to the end users and by OOTB pega can use the contact information available in the Operator form.
Application Access – You can specify ‘n’ number of access groups for an Operator ID, but remember only one can be active at a time.
Check the Radio button to select the default access group.
Always remove, this is how the Operator gets access to an Application.
Operator ID -> Specify the Access group -> Specify the application
Localization –
Under the localization, you can specify the Default locale and Time zone configurations.
What is Localization?
– Localization supports accessing the same application in different regions. We know different regions use different languages, date formats. Pega supports this localization format.
– You can either specify to which localization should this operator belong to or you can also leave the Default locale empty.
The localization configuration works based on browser and application configurations.
For IE, normally the localization applies for all sites based on the below settings.
This can be overridden in the Pega application when we use Localization. We will discuss it later in a different lesson.
Work tab
This tab is more important for the End users operator configurations.
Routing
You can associate all the routing parameters with the Operator ID.
Organizational Unit – You can update the Organization / Division / Unit, the operator belongs to.
In the Enterprise class structure article, we looked in detail about the Organizational structure. It is mandatory to associate Operators with an Organizational structure.
By this way, you can tag an operator with a certain hierarchy and can be used in routing, approval or other reporting processes.
Work Group – You can specify the workgroup the user belongs to.
As the name suggests, it is simply a group of people related to their work. You can just translate this to team names.
You can add one or more Teams to an Operator record but only one active at a time, which becomes the default workgroup of the operator.
If you open this workgroup, you will also find you can configure a work basket (where tasks can be assigned to the team) and a reporting manager for the workgroup.
Workgroup is another handy configuration that can decide to whom the case can be routed and worked upon.
Reports to – You can specify another Operator ID here, who acts more as a reporting manager to this operator ID.
The property .pyReportTo holds the value. This field comes in handy when you want to escalate or sent notifications, approval requests to the reporting manager of the Operator.
Skill and rating – You can specify a skill rule here.
Skill is a rule configuration in Pega which is technically a data instance.
Mostly we can use Language skills, especially for Customer service applications, So that customers with language preferences can be rightly handled by the Operators with the right skills.
You can also specify a rating based on the skill, that can further help with special treatment with highly skilled operators.
The rating can be specified in the range of 1-10
GetNextWork Configurations
The below part in routing belongs to GetNextWork.
What is GetNextWork?
– It is simply a button on a user portal. When you click it, it displays a new assignment for you to work. Instead of User choosing what case they can work on, the system can decide based on Urgency deadline, based on priority can pull the right work for the end user. Basically saving the time in choosing the next best work.
– GetNextWork can pull work assignments either from your worklist or workbasket.
Imagine when there are no items available in work list, the user can click on GetNextWork to pull a new assignment to work. It pulls the assignments from workbasket the user belongs to.
You can think users can manually pick work items from the workbasket. Yes, they can, but there are chances that he/she may pick irrelevant items. To avoid this Pega provides GetNextWork functionality to pick the item.
Workbasket – You can specify as many workbaskets as you want. Remember this does not restrict users from accessing other workbaskets.
The order that you specify in the work group array is very important unless you use Merge work queues checkbox. We will see about this shortly.
Then you can get three interesting checkbox configurations
Get From work queues first –
When true – GetNextWork checks the assignment from workbasket first, and then only it checks the worklist.
When false – GetNextWork checks the assignment from the worklist first, and then it checks the workbasket.
Use all work queue assignments in the user’s team –
When true – The workbasket array which we saw just now disappears. It just assembles all the workbasket assignments from the teams.
Remember we saw that in Workgroup/teams, we can specify the work queue/workbaskets
Merge Workgqueues –
When true – The order of the workbasket array listed above is not important. GetNextWork assembles all the assignments from the workbaskets and picks the most relevant item.
When False – The order of workbasket array listed above is important. GetNextWork first checks the assignment from the first workbasket. If no assignments are found, then it checks the second and goes on.
Use all workbasket assignments in User’s workgroup – visible when merge workbaskets is true.
Availability
In this block, you can configure the operator availability, and absent period and specify what happens when the operator is absent.
Operator is available to receive work – Check this to make the operator receive work through router activities.
Note: Activity of type router checks a parameter (this parameter) first before routing the assignments to his/her worklist. If this is unchecked, then the assignments get routed to substitute operator/Manager and the assignment will never reach this operator.
You can also tag a business calendar with the Operator record.
Scheduled absentees –
You can specify the Unavailable period of the operator record. This helps with duty roster in scheduling the work for operators
You have the option to add more than one-time range for the Unavailable period.
Substitute operator configurations
Substitute Operator type – The substitute operator can be either Operator or workbasket.
e) Decision tree to find substitute – You can specify a decision tree, if you have a complex logic to find the substitute.
Default to assignee – You can specify either an Operator or a Workbasket name here to make a default substitute.
Security tab
Update password – You can update the operator password here. When you manually create a new operator, it is mandatory to specify the Password and it is recommended to also enable force password change on the next login checkbox.
Allow rule checkout – If enabled, you can Checkout or private edit the rule, Restore options are available when you enable it. This should be enabled only for developers and for end users this should be disabled.
Tip: In production don’t have multiple operators with check-out enabled. Pega forms ruleset cache based on the ruleset list and when you have check-out enabled with your own private ruleset, it will be treated as unique ruleset list, so if many have check-out enabled, there will be lot fo unique ruleset cache be created.
Use external authentication –
When true – Mark this when you don’t want to use any basic authentication – Username and password to login for this pega account. Use this option only when you have properly set up an authentication service with external IDP.
When false – This is the default configuration where the basic authentication will be used.
Force password change on next login – This is a clear description and you know when to use it 😊
Disable Operator – You can always suspend or disable the operators from the system/
Note: There is an OOTB security policy feature to disable an Operator ID after a certain period of inactivity.
Starting activity to execute – Data.Portal.ShowDesktop
This is a default OOTB activity. Never update this!.
License Type –
Named – For operator ID instances accessing through web browsers – default value.
Invocation – This Operator ID is used for processing service calls. We use it rarely.
Important Points to Consider.
– On completing/creating the Operator rule form and saving create a new entry to pr_operators table in the data schema.
– pr_operators table contains many columns like ‘pyUserIdentifier, ’pyAccessGroup’ etc., which contain all the configuration details about the operator ID.
– To Identify the exact property name/column name/field name of the Operator configurations, use Live UI on the Operator rule form and check various fields in Operator ID form.
For example – You can see Email address gets saved in a pagegroup property – pyAddresses().pyEmailAddress
You can also see pyReportTo property.
All these properties get saved as separate columns in pr_operators table.
You can check all the Operator ID details on the clipboard system pages.
At run time case processing, you can refer to this OperatorID page at any place!! The current operator details will always be available.
Hope you are clear with the basics!
