Personas, operators, and work access
Pega Platform™ applications manage users, their access privileges, and work routing through Personas, operators, Access Groups, and Access Roles.
- A Persona represents a group of users for your application that corresponds to their needs as they interact with an application.
- An Operator is a specific user that performs work in your application.
- An Access Group is a group of privileges in the system.
- An Access Role defines the classes that a user can view, update, and delete.
Personas, operators, Access Groups, and Access Roles combine to determine what work a specific user can perform in an application.
As a Pega Business Architect (BA), it is unlikely that you are responsible for creating these artifacts in the application. However, you work with business stakeholders to identify the application's primary user groups. Then, you communicate the differences between the primary user groups to the IT teams so that they can create the appropriate Personas, Access Groups, and Access Roles to support the Case Type workflow.
In this topic, you explore the relationship between Personas, operators, Access Groups, and Access Roles so you can ensure that users of your application have the privileges required to perform their Tasks in the most secure and efficient manner possible.
Personas
Each Persona represents a group of users for your application, defined by their business role, tasks, and objectives in relation to the business process. The purpose of a Persona is to create consistent and realistic representations of your primary system user groups so that the application can address their needs, expectations, and behaviors.
Operators
In Pega Platform, each specific user that interacts with an application is identified as an operator. Each operator has a unique identifier (usually an email address), a password, and personal information, including relevant skills.
Operators complete Assignments in an application so that business processes can reach a successful resolution. For example, in an application for reviewing loan requests, developers can create operators for a CSR, a reporting manager, and a loan administrator to review, approve, and process the loan application.
In the following image, click the + icons to review the benefits operators provide to an application:
Developers create operator records to establish users in an application. The operator record must include an identifier, usually an email address, and a unique password for security. If the information is available, the operator record can also include the individual users defined skill set and information about substitutions during absences. By default, every user has a Worklist from which they receive their assigned Tasks.
Next to the identifier and password, one of the most important aspects of establishing an operator record is the assignment to an Access Group.
Access Groups
Access Groups represent a group of privileges in the system. The Access Group privileges define the access of an operator to:
- Relevant applications: rulesets and versions
- Available portals (including the App Studio, Dev Studio, and Admin Studio)
- Available work pools (the set of all work objects that are open and resolved)
- Available Access Roles
After the creation of an operator record for a user, that user receives an assignment to an Access Group that determines which applications, and which parts of those applications, that user can access.
An operator can belong to multiple Access Groups and switch between them, but only one Access Group is active for a given operator at a given time.
Access Groups and Personas
Access Groups are defined for operators who have similar responsibilities. In that respect, Access Groups sound similar to Personas. When users create a new Persona for an application in App Studio, the system automatically creates a corresponding Access Group of the same name. For example, in a Loan application, after the creation of a Managers Persona in App Studio, the system creates a Loan:Managers Access Group in Dev Studio.
However, it is important to recognize that Personas and Access Groups are not identical. A Persona is a broad user group created and available only in App Studio. An Access Group is a group of specific permissions in an application that determine the work an operator has permission to do. Access Groups are available only through Dev Studio.
Access Groups and work groups
Although they might seem similar, it is important not to confuse work groups with Access Groups.
Access Groups are a set of privileges that determine which applications and parts of those applications users can access. The Access Group for users determines which work pool (the set of open and resolved tasks) users can access. Access Groups control much more than just a user’s access to work.
Work groups are defined solely to distribute work across the cross-functional team that was created to support the business process that you, as a Pega BA, had an integral role in redesigning.
Access Roles
Although Access Groups are defined for operators with similar responsibilities, not all operators in that Access Group might need or have access to the same permissions. For example, a Manager in the Loan department and a manager in the Credit department are both members of the Manager Access Group. Both managers need access to the same Consumer Finance application and Portals. However, the Manager in the Loan department must be able to view, update, and delete information only for Cases opened from the Loan Case Type. The Manager in the Credit department should have permission for the same functionality but only for the Cases opened from the Credit Case Type.
Each Access Group is associated with a set of Access Roles. With Access Roles, users have granular control over permissions and privileges within an Access Group. An Access Role defines a specific job function, position, or responsibility for an application. The Access Role determines the classes that a user can view, update, and delete in an application.
As a Pega BA, you work with business stakeholders to assess the role-based access control (RBAC) needs for the application to determine how many distinct Access Roles are needed. From there, you work with the IT team to associate the access role requirements with the Access Groups and Personas, ensuring that all the different groups and roles for applications have what they need to navigate the workflows successfully.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?