Design access and information protection
Topic 2 established how work reaches the right user when several users represent the same Persona. The Blueprint now identifies the responsible Persona, the routed Assignment, and the operating conditions that influence ownership, eligibility, continuity, and work selection.
The focus now shifts from who can receive the work to what that participant may see and do while performing it. Access must enable each Persona to fulfill its responsibility, but it must also protect information, actions, and records that the work does not require.
For Tour Booking, a Customer needs to create and manage a booking through a guided self-service experience. A Tour Operator needs the information required to coordinate preparation and resolve routine operational issues. A Branch Manager needs access to exception evidence and the authority to record an approved decision. Each Persona requires enough access to complete legitimate work, but not unrestricted access to every booking, every customer detail, or every action.
Solution Designers begin with the complete responsibility of each Persona and establish broad Case Type and Data Object access in Pega Blueprint™. They then refine the model by evaluating data sensitivity, Assignment ownership, Case context, service pathway, and customer rights. The result is a Blueprint that clearly explains what each participant may see and do, why the access is required, and how the decision changes when the context changes.
Establish the broad access boundaries
Start with the complete responsibility of each Persona. Confirm which Case Types the Persona must create, read, or edit, and which Data Objects the Persona must create, read, edit, or delete. Review the permissions available through the current access controls in Blueprint and refine the generated access accordingly.
The following figure shows how access boundaries define the information, actions, and responsibilities available to each Persona in the Tour Booking application:
These routine responsibilities establish the starting access model. The Solution Designer then tests whether those boundaries support legitimate variations in the Case Type. A Branch Manager may need to create a booking on behalf of a Customer during an assisted-service pathway. An escalation may require temporary access for a different responsible user. A business-continuity process may allow a substitute participant to act when the expected user is unavailable.
Exceptional access should not be added just because it might be convenient. It should support a confirmed responsibility or pathway, and the business reason should be recorded clearly for Authoring.
Note: Use Persona Case Access to define create, read, and edit permissions for Case Types. Use Persona Data Access to define create, read, edit, and delete permissions for Data Objects.
Tip: Test the routine journey, Alternate Stages, assisted-service pathways, escalations, and business-continuity scenarios before confirming the broad access boundary.
Refine access to sensitive data and significant actions
Broad Case Type and Data Object permissions may provide more access than a Persona needs for a specific Step, decision, or interaction. After the broad boundary is established, evaluate the data and actions required to complete the work.
Applied to Tour Booking, a Tour Operator preparing a tour may need to know that a participant requires mobility assistance and how that requirement affects equipment, staffing, or timing. The Tour Operator does not need unrelated medical information, payment details, or full customer account history. The Tour Operator may need to view the operational requirement without being able to change the original information of the participant.
This distinction matters because viewing, changing, and deleting data create different consequences. Access should be designed around the work being performed, not around the assumption that a participant with access to the Case should also see or change everything connected to it.
The following figure shows the considerations used to align access permissions with job responsibilities while protecting sensitive information. For each meaningful interaction, determine:
Note: A View presents the data and actions required for an interaction. Authorization enforces whether the user may access the underlying Case, record, property, or action. Keep the View aligned with the enforceable access requirement.
Tip: Trace each item of data to the Step or decision that uses it. Provide the access needed to complete the work and protect data or actions that serve no confirmed purpose in that interaction.
Once the required data and actions are clear, identify the business condition that controls any additional restriction.
Identify what controls each access decision
The same access requirement can arise from different business conditions. The responsibility of a Persona may establish broad access. Assignment ownership, location, Case state, service pathway, or information sensitivity may narrow that access. Customer privacy rights may require personal data to be accessed, corrected, restricted, retained, or removed across the application landscape.
The Solution Designer should describe the business condition first, then state the required access result. This creates the evidence needed during Authoring to select and configure the appropriate authorization controls. The following figure shows how access control models align access permissions with persona responsibilities, business context, and personal data rights:
Applied to Tour Booking, the role of a Tour Operator may provide broad access to perform preparation work. But access to participant details may depend on whether the Tour Operator is assigned to that booking, whether the tour is still active, or whether the information is sensitive. A Branch Manager may require exception evidence while making a decision, but not permanent access to every detail after the exception is resolved. A Customer may have rights related to personal data that must be handled consistently beyond a single Assignment.
Tip: Describe the business condition and required access result before considering the authorization model. Several authorization models may contribute to one security decision.
These approaches often work together. The next step is to test whether the access decision still holds as the business context changes.
Test access as circumstances change
Access that supports one situation may become too broad or too limited when the Case context changes. The Solution Designer should test each significant permission by changing the condition that justified it.
A Tour Operator may need participant data for an assigned tour without needing the same information for an unrelated booking. A Branch Manager may require exception evidence while making a decision, but that access may change once the exception is resolved. A Customer may be able to view and update information during the guided booking journey, but certain changes may require assistance, verification, or exception handling after confirmation.
Test access by changing conditions such as Assignment owner, Case state, service pathway, branch location, data sensitivity, or customer privacy request. The following figure shows the key questions used to validate whether access remains appropriate as work conditions, Case states, and business needs change:
Apply the principle of least privilege to the resulting design. Retain the access needed for every confirmed responsibility, Step, or decision. Remove access that serves no confirmed business purpose.
Tip: Record the business purpose for significant or exceptional access through the relevant access setting and a focused Note. Use the Persona description only where the access arises from the Persona’s enduring responsibility.
Review the security model
The final test is whether the security model supports the complete participant design without unnecessary exposure. Follow representative participants through routine, exception, assisted-service, and recovery pathways.
For Tour Booking, trace a Customer through self-service booking and updates. Trace a Tour Operator through routine preparation, customer follow-up, and specialist operational work. Trace a Branch Manager through exception review and authorization. Then test what changes when the Case moves to another state, another user owns the work, the service pathway changes, or sensitive information is involved.
The following figure shows the key questions used to assess whether a security model is complete, practical, and aligned with business needs. Confirm that:
Note: Stakeholders can explain what each Persona may see and do, why each significant permission exists, what controls each restriction, and how access changes when ownership, Case state, service pathway, or data sensitivity changes
Summary
Access design turns the participant and operating model into a secure, usable application experience. Persona Case Access and Persona Data Access establish broad access boundaries in Blueprint. The Solution Designer then refines those boundaries by evaluating the data and actions required for specific work, identifying what controls additional restrictions, and testing the result as circumstances change.
For Tour Booking, the access model ensures that Customers, Tour Operators, and Branch Managers can complete legitimate work while protecting information and actions that their responsibilities do not require. Role-based access control (RBAC), attribute-based access control (ABAC), and client-based access control (CBAC) provide implementation awareness of how different access requirements may be realized during Authoring. Least privilege confirms that each participant receives the access required for their work without unnecessary exposure.
The Blueprint now contains validated Personas, operating decisions, access intent, and Channel information. The next design question is how that intent carries into Pega Infinity™ through users, work distribution, authorization, and application experiences.
Knowledge check
Check your knowledge with the following interaction.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?