Personas, operators, and work access

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.

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.

Match the numbers to the following image to review the benefits operators provide to an application:

1. Unique password: To improve security, every operator has a unique password with which to log in to the application. As a result, the password protects data and operations from inappropriate or random users.
2. Relevant access type: Developers can define access to specific data and work operations at the operator level by ensuring that the users of the application can perform only the actions that are relevant to their role.
3. Substitution during absence: Provides a designated alternative when an operator is unavailable to perform their work.
4. Substitution during absence: Provides a designated alternative when an operator is unavailable to perform their work.

5. Access to shared Work Queue: Operators can access a Work Queue that groups Assignments for a team of which they must be a member. By using the Get Next Work feature in Pega Platform, an application can evaluate Tasks in the Work Queue and route the most appropriate Assignment to individual Worklists based on criteria such as Assignment Urgency, operator skillset, and operator availability.

6. Individual Worklist: Every operator has an individual queue of Assignments to complete that Pega Platform refers to as a Worklist. 

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
• 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 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, 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, the system creates a Loan:Managers Access Group.

However, it is important to recognize that Personas and Access Groups are not identical. A Persona is a broad user group. An Access Group is a set of specific permissions in an application that determine the work an operator is permitted to perform.

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 had an integral role in redesigning.

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.

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: