Personas and participation

The Case Lifecycle provides the foundation for the generated Personas in Pega Blueprint™. Each user-driven Step and interaction should be treated as evidence of participation. The Solution Designer traces the Case from initiation to resolution and asks what each interaction reveals about responsibility, authority, contribution, or awareness.

Applied to Tour Booking, capturing booking details, confirming operational viability, preparing equipment, collecting participant information, and confirming the booking involve different kinds of participation. Some participants perform work. Some provide information. Some apply judgment. Some monitor progress. Some receive the result.

Communication also reveals participation. A message can guide an assignee, notify someone that work has been routed, request approval, alert a responsible participant to a Service-Level Agreement (SLA" commitment, or communicate a Case event or outcome. The design question is not only who receives the communication. It is what the recipient needs to know or do, why the communication matters at that point in the Case, and whether it indicates a distinct responsibility in the design.

For example, a Tour Operator who prepares equipment and resolves routine booking issues contributes directly to operational progress. A Branch Manager who reviews an exception contributes a different kind of authority. A Customer who supplies information and receives booking updates participates through a guided external experience. These are different participation patterns, and each may require a distinct Persona.

 A Persona is the business representation of a type of user. Define each Persona around a responsibility that remains meaningful even when individual people, team structures, or job titles change.

Organizational structure does not, by itself, determine the Persona model. People in the same department may require different authority, access, routing, or interaction methods. People in different departments may fulfill the same responsibility through the same experience. The Solution Designer evaluates the design effect of the difference, not the label attached to the person or team.

Create a separate Persona when the difference affects the application design in a meaningful way. The difference may involve the work participants receive, the authority they exercise, the information they can access, the Channel they use, or the experience they require. Keep one Persona when the difference reflects staffing, location, or reporting arrangements that do not change routing, access, or interaction needs.

Applied to Tour Booking, Tour Operators perform recurring operational work such as confirming tour feasibility, coordinating preparation, and resolving routine booking issues. Branch Managers authorize defined exceptions and provide branch-level accountability. These differences affect responsibility, routing, authority, and access, so they support separate Personas.

By contrast, Tour Operators working in different branches can usually share the same Tour Operator Persona when they perform the same work, require the same access, and use the same experience. Their branch location may matter for routing or workload management, but it does not automatically create a separate Persona.

Responsibilities explain why a Persona exists. Tasks provide evidence of what that Persona must accomplish. After identifying candidate Personas, review the related tasks, Assignments, communications, and decisions to confirm that each Persona represents one coherent responsibility rather than several unrelated participant groups.

In Tour Booking, a combined “Operations User” Persona might seem efficient at first, but it can obscure important differences. If Tour Operators coordinate preparation while Branch Managers review exceptions, combining those responsibilities can make routing, access, and authority unclear. Separating them helps the design communicate who performs routine operational work and who applies management judgment.

The opposite risk is over-splitting the model. Creating separate Personas for “North Branch Tour Operator” and “South Branch Tour Operator” may provide no design value if both groups perform the same work through the same experience. Branch may still be useful as a routing condition, but it does not have to become a Persona.

The following figure shows a Persona assessment framework for identifying meaningful design differences while avoiding overly broad or overly narrow personas. Evaluate each Persona by asking:

Persona design becomes clearer when the Solution Designer distinguishes shared responsibilities from Case-specific relationships and individual runtime identities.

A Case participant is a person, business, or organization connected to a specific Case. A Customer, Owner, or Interested participant may have a meaningful relationship to one Tour Booking even if they are not assigned work. A Persona represents a group of users with shared responsibilities and interaction needs. A user is an individual who interacts with the application. An Operator is the specific Pega user represented through an Operator record in Pega Infinity™.

These concepts answer different design questions. A Customer may be a participant in one Tour Booking because that person is connected to that specific Case. Customer may also be an external Persona because customers share a common interaction pattern: they request a booking, provide information, receive updates, and complete guided self-service interactions. A Tour Operator is an internal Persona represented by multiple users who perform recurring operational work. Each individual Tour Operator is later represented in Pega Infinity through user and Operator configuration.

Understanding the distinctions between Case participants, Users, Personas, and Operators helps ensure accurate application design decisions, as shown in the following figure:

Distinguishing these concepts prevents the design from mixing business responsibility, Case relationship, and runtime identity. Each informs different decisions about routing, access, Channels, and implementation.

Whether a Persona represents internal or external users affects the design, but the internal or external label does not by itself justify a separate Persona. Create a separate Persona only when the responsibility, routing, access, or interaction needs require it.

Internal Personas commonly require work routing, shared work management, qualifications, availability, team-based Assignment, and application access. External Personas commonly require self-service, authentication, information protection, guided interaction, notifications, and experiences suited to occasional use.

In Tour Booking, the Tour Operator is an internal Persona because the responsibility involves recurring operational work inside the application. The Customer is an external Persona because the responsibility involves requesting a booking, providing information, and receiving updates through a guided self-service experience. The Branch Manager is also internal, but the reason for a separate Persona is not simply that the user is internal. The reason is that the Branch Manager applies defined authority to exception decisions.

Blueprint uses the application context and Case Design to generate a starting Persona set. Treat that set as a proposal, not a final answer. Compare each generated Persona with the participation evidence from the Case Lifecycle, stakeholder input, routing needs, access needs, and Channel expectations.

Retain strong suggestions when the Persona reflects a meaningful responsibility. Rename a close match when the intent is correct but the language is unclear. Add a missing Persona when the Case requires a distinct responsibility that Blueprint did not identify. Combine redundant Personas when separate names do not create meaningful design differences. Remove a Persona when it creates no distinct responsibility, routing, access, authority, or interaction need.

The target is the smallest Persona set that represents every meaningful participation difference in the design. Numerical guidance can be useful as a prompt, but it should not become a fixed limit. The Persona set is complete when it explains the operating model clearly enough to support later routing, access, Channel, and Authoring decisions.

The following figure shows a Persona reconciliation guide for evaluating AI-generated Personas and determining whether to retain, rename, add, combine, or remove them:

A Persona name identifies the participant group. The description should explain the responsibility that gives the Persona a distinct place in the design. A strong description helps stakeholders understand why the Persona exists and gives Blueprint better evidence for generating access, routing, and Channel suggestions.

Describe the responsibility in terms of meaningful work, authority, or participation. Avoid descriptions that simply restate a job title or department. The description should explain what the Persona contributes to the Case and why that contribution matters.

Distinct Personas are defined by their responsibilities, accountability, and interaction needs, as shown in the following figure for the Tour Booking Case:

After refining the Persona set, trace each Persona across the Case Lifecycle. Identify where the Persona initiates work, performs an action, supplies information, applies judgment, monitors progress, or receives an outcome. Confirm that each interaction aligns with the responsibility described for the Persona.

Then consider the context in which each interaction occurs. Evaluate frequency, location, guidance needs, device needs, security needs, and delivery scope before selecting a Channel. A Channel should support a confirmed interaction need, not simply reflect a preference or future possibility.

Applied to Tour Booking:

• Customer: Web Self Service supports the guided booking journey, participant information collection, and booking updates.
• Tour Operator: Web supports recurring operational work, preparation coordination, and issue resolution.
• Branch Manager: Web supports exception review, authorization, and intervention.

One Persona may use several Channels, and several Personas may share the same Channel. Record a Channel planned for a later release as future design intent while keeping it outside the current delivery scope. If the solution requires Channels not directly available in Blueprint, such as conversational, messaging, or voice Channels, capture the intent in Blueprint so that it can be considered during Authoring.

 The following figure shows the four-step approach for evaluating and determining Persona responsibilities:

The final test is whether the Persona model explains how people participate in the Case Type as one connected design. Review the Persona set against the Tour Booking Case Lifecycle, the routing model, the access model, and the expected user experience.

The following figure shows a checklist for reviewing and refining a persona set to ensure that each persona represents a meaningful and distinct responsibility:

Persona design turns the Case Lifecycle into a coherent participant model. Experienced Solution Designers evaluate the generated Personas in Blueprint against stakeholder information, Case participation signals, routing needs, access needs, and Channel expectations. They define Personas around stable responsibilities rather than job titles or organization charts.

For Tour Booking, the Persona model explains how Customers, Tour Operators, Branch Managers, and other participant groups contribute to the Case journey. That model becomes the foundation for routing, access, Channels, experience design, and later implementation in Pega Infinity.

The next Solution Design question is how Assignments reach real users when several people represent the same Persona.

Check your knowledge with the following interaction.