Persona and Channel Design in Pega Infinity

Blueprint Personas identify who participates in the work and why they are required. Each Persona represents a distinct business responsibility and establishes how a participant contributes to achieving the business outcome.

When Blueprint is translated into Pega Infinity, that participant model becomes a combination of user identity, application access, Channel experience, and Case participation. Multiple Pega Infinity constructs work together to preserve the intent of a single Persona.

A Solution Designer should therefore avoid evaluating these constructs individually. Instead, they should follow the participant journey from the validated Persona to the user who performs the work and confirm that the participant can access the application, understand their responsibilities, and contribute to the Case as intended.

The following figure shows how Blueprint design concepts are mapped to Pega Infinity constructs while preserving the intended user experience and business context:

Review the participant journey

Consider the Tour Operator Persona from the Tour Booking application. Blueprint establishes that the Tour Operator confirms operational viability and prepares tours for delivery.

After import, this responsibility is represented through several connected Pega Infinity constructs. The Operator record identifies the individual user. The Access Group establishes the application and permission context available to that user. The selected Channel determines how the participant interacts with the application, while Case participant information preserves the relationship between the Customer and the Tour Booking Case.

Together, these constructs allow Pega Infinity to translate a business participant defined in Blueprint into a user who can securely access the application and perform the required work.

The Blueprint operating model defines how work reaches the people who should perform it. During design, stakeholders validate ownership, responsibility, qualification requirements, escalation expectations, and continuity needs.

Pega Infinity translates these decisions into work distribution structures that determine how Assignments are routed, shared, selected, and completed. The resulting implementation may involve Worklists, Work Groups, Work Queues, skills, substitution settings, and work-selection mechanisms.

A Solution Designer should focus on whether the overall operating model remains intact. The specific implementation components are important, but their primary purpose is to preserve the validated ownership and responsibility model established in Blueprint.

Blueprint design	Tour Booking example	Pega Infinity construct	Design intent carried forward
Individual ownership	Return a customer clarification to the Tour Operator familiar with the booking	Operator and individual Worklist	One identified user owns the Assignment where continuity creates business value.
Shared ownership	Keep routine equipment preparation available to Tour Operations	Work Group and Work Queue	Any eligible team member can progress work that carries shared responsibility.
Additional qualification	Require a Tour Operator qualified for marine excursions to complete the safety check	Operator skills and eligibility	Specialist work reaches a user with the required capability.
Continuity during absence	Allow another qualified Tour Operator to complete time-sensitive preparation	Operator availability and substitution	Work continues while preserving the required capability or service expectation.
Automated work selection	Select preparation work using implemented priority, qualification, and availability criteria	Get Next Work	Work selection supports the agreed service and operational outcome.

The following figure shows how business requirements for work ownership and routing are realized through Pega Infinity configuration options:

Review how one Assignment reaches a user

In the Tour Booking application, routine equipment preparation remains available through a Work Queue associated with the Tour Operations Work Group. Individual Tour Operators are connected to that team through their Operator records, allowing eligible users to perform the shared work.

Where additional expertise is required, such as marine excursion qualifications, Operator skills provide an additional routing consideration. Availability and substitution settings help ensure that work continues when the originally expected user cannot act.

Get Next Work can then select Assignments from a user's Worklist or associated Work Queues according to the implemented business rules and selection criteria.

The important design question is not which routing mechanism was used. The important question is whether the implemented routing preserves the validated ownership, qualification, continuity, and service expectations established in Blueprint.

Distinguishing application access from work distribution

Application access and work distribution are closely related but serve different purposes.

The Access Group determines the application context and permissions available to a user. Work Groups and Work Queues determine how work is shared and distributed among eligible participants.

A single Operator can therefore be connected to both structures. One determines what the user can access, while the other determines which work the user can perform.

Blueprint defines both what participants can access and how they need to work. Persona Case Access, Persona Data Access, focused Notes, selected Channels, and Blueprint Preview collectively establish the validated participant experience.

When translated into Pega Infinity, these decisions become a combination of authorization controls and user experiences.

These two areas should always be evaluated together. Authorization determines whether access is permitted, while Views, Portals, navigation, and landing pages determine how participants experience that access. A successful implementation preserves both the security intent and the usability intent established during Blueprint design.

The following figure shows how persona access requirements are implemented through security controls, contextual permissions, and application experiences:

Authorization and experience through one Assignment

Consider the Confirm operational viability Assignment in the Tour Booking application.

RBAC establishes the broad permissions associated with the Tour Operator responsibility. ABAC can introduce additional conditions based on Assignment ownership, Case Status, location, or data sensitivity.

The Assignment View then presents the information and actions required to complete the work, while the Full Page View provides access to wider Case context and supporting information.

These interfaces should reflect the authorized access of the participant without becoming the security mechanism themselves. Authorization determines what is permitted. The experience determines how that permitted information is presented.

Use Blueprint Preview as experience evidence

Blueprint Preview enables Solution Designers to review the participant experience with stakeholders and refine the underlying Blueprint in the same environment.  Changes made through Live Edit, the AI Assistant, or Content controls update the underlying design. Use Preview to examine:

• The current Assignment and required actions
• The Case summary and lifecycle
• Wider Case details and related data
• The Cases available to the participant
• Work, measures, and information presented through Home
• Differences between selected Channels

The following figure shows the current Assignment, Case summary, Lifecycle, and broader Case details:

The following figure displays the available Case Types:

The following figure shows the supplied Blueprint Preview Home where users can review operational measures, visualizations, Worklist, announcements, Pulse, navigation, and the Channel selector:

Develop Channel intent into Portal experiences

The Blueprint identifies how each Persona intends to interact with the application through Web, Mobile, or Web Self Service channels.

During Authoring, Solution Designers should evaluate whether the available Portal experience supports that interaction need. The goal is not to create separate experiences unnecessarily, but to ensure that each participant can efficiently perform their responsibilities.

Portals provide the overall working environment, while Views, landing pages, and navigation support more focused interactions. Together they create the participant experience required to complete work across Assignments, Cases, and broader responsibilities.

Solution Builders typically begin with standard Portal capabilities and then refine the experience where the participant's work requires additional support. Throughout this refinement process, presentation decisions should continue to support the validated participant experience while authorization controls continue to enforce access.

The following figure displays a Pega Infinity standard work Portal:

Blueprint import creates an application foundation that reflects the selected implementation scope. For Persona and Channel Design, this means translating validated participant responsibilities into the Pega Infinity structures required to support them.

A Solution Builder evaluates each Persona within the selected scope and determines which related assets should be created or connected as part of the imported foundation.

Import does not complete the implementation. Instead, it establishes a starting point that preserves the validated design and provides a basis for continued Authoring.

What import establishes

Where supported, Persona import can establish:

• Persona-related Access Groups and Access Roles
• Permissions derived from the Blueprint design
• Portal or Channel configuration
• Work Queues for Personas used in Assignment routing

The following figure shows how persona responsibilities drive key application design decisions, including access controls, web channel experiences, and routing structures: 

These generated assets should be treated as implementation foundations that require validation against the original Blueprint design.

Use Blueprint release planning and effort sizing to show when each confirmed Persona and Channel enters delivery and the relative effort required. Keep future-release intent visible without including it in the current import scope.

Tour Booking example

In the Tour Booking application, the Tour Operator Persona is required because several user-driven Steps route work to that participant.

The imported foundation should therefore preserve:

• The Tour Operator responsibility
• Required Case and Data Object access
• The selected Web Channel experience
• Routing structures that support shared operational work

The following figure shows the design considerations that emerge from defining Persona responsibilities and access requirements:

The Solution Designer and Solution Builder should validate these generated assets against the Blueprint and confirm that the resulting implementation continues to support the intended participant responsibilities, access boundaries, ownership model, and interaction needs.

Authoring continues

The Solution Builder continues to refine:

• Operator records and authentication
• Access Groups and Access Roles
• Authorization controls
• Work Groups and team structures
• Skills, availability, and substitution
• Work-selection behavior
• Portal composition, Views, landing pages, and navigation

Persona and Channel Design establishes who participates in the application, how work reaches them, what information they can access, and how they interact with the solution. Pega Infinity translates these validated Blueprint decisions into identity, application access, work distribution, authorization controls, and participant experiences. The Solution Designer works with the Solution Builder to verify that the generated Pega Infinity foundation preserves the responsibility, ownership, qualification, access, and interaction intent established during Blueprint design. Blueprint import provides the initial implementation foundation, while Authoring progressively refines that foundation into a complete working solution.

Check your knowledge with the following interaction.