Skip to main content

Blueprint best practices for Case Lifecycle design

Pega GenAI Blueprint™ is an essential part of the discovery and delivery success of a Pega project. Although Blueprint incorporates Pega’s best practices for Case Lifecycle design, it is important that you, as a Pega Business Architect (BA), review the information to ensure that those best practices are followed. Below is a list of considerations for you, as the BA, to keep in mind as you either create the initial Blueprint with the client or review the various Blueprint elements with stakeholders in anticipation of the handover of the Blueprint to the project's Lead System Architect for import into Pega Platform™. 

Application Context

Application context on the Blueprint progress bar.

It is important that the application's context describes the workflow as accurately as possible, because this information determines the application design proposed by Pega GenAI. Perform the following actions regarding the Application Context to generate the Blueprint:

  • Confirm that the application is for a unique business process, or if an industry-provided template can be used to create the Blueprint.
  • Confirm that the Industry, Sub-industry, and Department/function accurately identify the business process, because they play a considerable role in the recommendations from Pega GenAI. If Other is selected, the documentation should clearly explain the specific business process to avoid any bias coming from Pega GenAI. 
  • Confirm that the information defined in the Application purpose accurately reflects the application, because this information is displayed in the header of the application when you preview it in Blueprint.
  • Confirm that the Functional Description accurately identifies the high-level information for the application. This information can include Microjourneys® or business processes, systems integrations, channels, and Personas.

Workflows

Case types highlighted in the Blueprint menu bar.

In Blueprint, each Workflow is defined as a Case Type. It is important that the Case Types proposed by Blueprint accurately reflect the work that is expected to take place. Perform the following actions in relation to each of Blueprint's proposed Case Types:

  • Confirm that each Case Type combines the process, data, and intelligence that is needed to drive standardized and guided work to achieve a single business outcome.
  • Confirm that the Description of the Case Type communicates the purpose of the Microjourney.
  • Identify the relationships and dependencies between Case Types. Identify the business processes that can occur independently but in parallel, processes that must occur sequentially, and parent/child Case relationships.
  • Identify the different Case status values that occur between Case creation and resolution.
  • Identify the Personas and channels to provide context for workflow activities.
  • If a new Case Type is built using a BPMN (Business Process Modeling Notation) file, confirm that the proposed Case Lifecycle matches the legacy information.

Workflow Details

Workflow details in the Blueprint menu bar.

Blueprint's Workflow Details section provides further information for each proposed Case Type. The Workflow Details section defines both the Case Lifecycle and the Case Data Model for each Case Type.

Case Lifecycle

Case lifecycle tab.

In Pega Platform™, the Case Lifecycle models the path that your Case follows to resolution, the Personas involved in completing that work, and the specific Assignments or Automations that must take place, and the time allotted to complete them. In Blueprint's Workflow Details section, each Case Lifecycle is a visual representation of the work that must be completed as part of the desired business transaction. The Case Lifecycle is defined as a series of Stages and Steps. Perform the following actions to evaluate each of Blueprint's proposed Case Lifecycles:

  • Complete the review of the proposed Personas in Blueprint in conjunction with the proposed Case Lifecycles.
  • Ensure that there is a logical starting Stage for each Case Type, and that there is at least one Resolution Stage.
  • Confirm that the Alternate Stage(s) represent exception scenarios or negative outcomes.
  • Identify any conditions required for Stage entry.
  • Identify relevant Service-Level Agreements for the Case Type, Stages, Processes, or Assignments.
  • For Steps, capture detailed information using the Notes field. Information to capture includes:
    • Assignment creation (sequential, parallel, Multi-step or Hierarchical Form)
    • Assignment instructions
    • Assignment routing (individual or Work Queue)
    • Case Status information
  • Check for redundant Stages and Steps across Case Types.
  • Use Blueprint’s Preview my app functionality to highlight the user experience to stakeholders.

Case Data Model

Case data model tab.

The Case Data Model defines the individual fields that are needed to resolve a Case. Perform the following actions to evaluate each of Blueprint's proposed Case Data Models:

  • Complete the review of the Data & Integrations step in Blueprint in conjunction with the Workflow Details step (Case Data Model tab) to confirm that each Case Data Model correctly references the corresponding data objects.
  • Verify that all proposed fields are relevant to the Case Type.
  • Use the field’s Description to capture business logic related to the field. This information is used by the technical team for contextualization during application development.
  • Review the Field Types available in Pega Platform to ensure that the fields and their related data records are appropriately captured and reflected in the application.
  • Identify relevant Primary fields to ensure that critical pieces of data are easily accessible during Case processing.
  • Use Blueprint’s Preview my app functionality to highlight the user experience to stakeholders. You can additionally use Pega’s out-of-the-box features for workflow transformation to do this.

Data & Integrations

 
Live data in the Blueprint menu bar.

In Blueprint, Data & Integrations contains the data objects that Blueprint identifies as relevant to the entire application, not just to any one specific Case Type. Perform the following actions to evaluate each of Blueprint's proposed Data & Integrations elements:

  • Complete the review of Data & Integrations in conjunction with the Workflow Details' Case Data Model tab to confirm that each Case Data Model correctly references the corresponding data objects.
  • For each data object, confirm that the Source of the information is clearly defined. If the data source is external to the application, confirm that the System of Record for the data source is clearly identified.
  • Use the data object’s Description field to capture business logic related to the data object for later contextualization during application development.
  • If new data objects are defined using OpenAPI ( formerly Swagger) or DDL (Data Definition Language) files, confirm what is depicted in Blueprint correctly reflects the legacy information.

Personas

 
Personas in the Blueprint menu bar.

Personas represent the users that will be performing the work at each Stage in the Case Lifecycle. They define internal and external Case participants who use the system in different ways based on their roles, resulting responsibilities, and desired business outcomes. Perform the following actions to evaluate each of Blueprint's proposed Personas:

  • Complete the review of the proposed Personas in Blueprint in conjunction with the Workflow Details' Case Lifecycles tab to provide context for the workflow activities.
  • Validate that the Personas identified accurately reflect who will be completing the work.
  • In the Persona’s Description field, document the channels in which this Persona is expected to work, the relevant Portals, and the set of Landing pages that should be available to complete their Assignments.

Summary

 
Summary on the Blueprint menu bar.

The Summary provides another opportunity to review Blueprint's proposed application. Perform the following actions as part of Blueprint's Summary process:

  • Partner with the project's Lead System Architect (LSA) and other stakeholders to review the entire application and ensure that the Blueprint is ready to be imported into Pega Platform to create a new Application. 
  • Confirm whether the client has an existing Pega application or applications in the target environment, and what Case Types and data assets this new application will reuse or inherit.
  • Export the Blueprint PDF for reference during the Blueprint import process.
  • Export the Blueprint file.

Refining the project Backlog

App Studio's Agile Workbench serves as the initial destination for the user stories created in the Blueprint import and used for your project backlog. As part of the Blueprint import process, Features, Sub-Features and User stories are automatically created for the tasks that need to be completed by the technical implementation team. These tasks include information detailed in the Description or Notes fields in each of the Blueprint elements.

Work with your LSA to plan the integration of Agile Workbench into the requirements management system that is used during the project.

 

Check your knowledge with the following interaction:


This Topic is available in the following Module:

Se hai problemi con la tua formazione, consulta ilPega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice