The path to creating high-fidelity Blueprints
High fidelity is not a quality label. It is a delivery threshold.
A high-fidelity Pega Blueprint™ is detailed enough that, when imported into Pega applications during the Authoring Stage, it produces a working application with minimal rework and achieves the agreed-upon business intent. Reaching that threshold is not an accident; a Blueprint reaches it through a specific sequence of decisions. This topic walks you through the five steps that determine whether a Blueprint meets that threshold.
Delivery impact
Building an application is like building a house. Case Types and workflows are the rooms. Personas and navigation are the doors and windows. Integrations are the electricity, plumbing, and connectivity that link the house to the surrounding infrastructure. The Blueprint is the architectural drawing that makes everything buildable.
A house built from a vague sketch has problems that appear only during construction. A house built from a detailed set of plans, where every dimension, every connection, and every material is specified, moves from foundation to completion without costly surprises. High fidelity is that level of detail. It forms the basis for estimation, stakeholder alignment, and speed in the Authoring stage.
The five steps to high-fidelity Blueprints
The five steps to high fidelity are applied during the Design stage of Blueprinting. They represent the five dimensions of the Blueprint that must reach sufficient detail before the design is considered build-ready.
Step 1: Application context
The Application Context is the foundation of the Blueprint and the input that provides the business intent that determines the outcome of everything that the AI generates.
What belongs here: the information the AI needs to render a useful baseline.
Note: The richer and more specific the Application Context, the more relevant the AI output. Less context produces a generic starting point. More context produces a starting point that requires far less rework.
Think of the Application Context as the architectural drawings of a house. If you want a garage and an additional bedroom, it has to be in the plans before the electrical designs begin. Adding them after the structure is built is possible, but you would have to regenerate the floor plans and electrical designs again. The same principle applies here: capture the major requirements (actors, personas, key processes, early thoughts on the data model) before generation begins.
Tip: At this stage, the concern is not cost but setting the foundation for your application. If you miss the Application Context, you need to add it to the blueprint before you can estimate the cost to build.
Step 2: Workflows
Workflows define the business journeys in the application: the Case Types that represent the work being done. Review the AI-generated Case Types, remove any that are out of scope, and confirm that the remaining ones have descriptions that accurately reflect the business process they represent.
On the generate/regenerate decision: Generating a Blueprint early and often is low-stakes. You can generate the same Blueprint multiple times until the output is close to the starting point you need. Regeneration makes sense when you want to test whether a different Application Description yields a better workflow baseline. The decision point where regeneration becomes costly is when you have invested significant time in manual refinement. After you have built up meaningful practitioner work inside the tool, regenerating means discarding that work.
The rule: regenerate freely before substantive refinement begins; hold the line after.
Step 3: Workflow details
This is where practitioner expertise does its most consequential work. AI-generated workflows are almost always low fidelity at first. You supply what AI cannot infer: business rules, decision logic, approval, automation, exception handling, SLAs, and persona-specific process variations.
For each workflow, define every stage and step. Aim for four to seven stages. Capture the 80% happy path first, then add alternate stages for exceptions and edge cases.
Use the Notes field within each stage to record any details that cannot currently be captured elsewhere in Blueprint. These notes are important because, when imported, they create a backlog of work for the Authoring stage. As Blueprint continues to add new features, more information is captured automatically. Use notes to document a level of detail that a builder may need in the Authoring stage. These entries become the foundation for work items in Authoring.
Use the Settings tab to define parent and child case relationships, attachment categories, and release planning (MLP 1 versus Release 2) for each workflow.
When documenting workflow steps, note reuse intent directly in the step description. If a smart shape, pre-built component, or existing connector already covers the functionality that a step requires, record that in the description field. When the Blueprint is imported, that description carries forward into the backlog as the user story. Reused intent captured in Blueprint becomes reused intent in the delivery backlog - automatically, without a separate handoff.
Step 4: Data and integrations
The Data Model is a key element of the Blueprint, shaping both workflow structure and user interaction. The level of detail in each object affects the AI-generated model shown in the preview. Clear and detailed field descriptions improve the accuracy of AI output for the Preview application and positively impact case data during the Authoring stage.
It is important to define the correct Field Types as well as to identify primary fields. Primary fields are displayed in the summary of a case during Preview, and are later part of the case summary in the application. Because all of these elements are created in each of the Data Objects on import, you gain a fully structured data model based on your blueprint.
Tip: Listing fields without a description produces a Preview that is generic and unconvincing. This is not a cosmetic difference - it is the difference between a stakeholder who validates the design and one who cannot evaluate it.
Every data object must be associated with a specific System of Record: an HRIS, a CRM, a Pega database, or an external API. That association is not administrative - it defines the solution's technical architecture.
Tip: Identify integration points early. Flag data objects that require external connections as this impacts estimations and project scope.
Step 5: Personas
Personas define who interacts with the application and how. Review the AI-generated Personas, remove any that are redundant or out of scope, and configure the remaining Personas by using the Persona settings.
For each Persona, define data access permissions (Create, Read, Update, Delete), Case access Rules, and release assignments. Map each Persona to the Case Types and Channels (web, mobile, email) that they interact with.
Summary
The following video explores why high fidelity is essential to successful delivery and how it provides a clear, shared understanding of what is being built before development begins. Using practical analogies, the session explains how layering application context, workflows, data and integrations, and Personas creates a complete and reliable blueprint. By consolidating fragmented documentation into a single source of truth and validating designs through preview, high‑fidelity Blueprinting reduces risk, improves estimation, and accelerates the transition from design to build.
You now have a Blueprint that has moved through all five steps and reached the design threshold. The question that remains is: how do you confirm this? Through "the Power of Preview," the validation mechanism that turns a completed Blueprint into a confirmed, stakeholder-approved design, as well as through the three dimensions of readiness that confirm that the engagement is ready to move into the Authoring stage.
Note: What constitutes high fidelity in Blueprint changes on a bi-weekly release cadence. New features, new Data Model features, and new workflow options are added with every release, which means the bar for what 'complete' looks like keeps moving. Check the Blueprint and App Design Expert Circle and the Blueprint release notes on Pega Documentation after each release to ensure that your understanding of high fidelity aligns with the current standard. A Blueprint that met the high-fidelity threshold two months ago may not meet it today.
Resources
For more information, see the following resources:
- Pega PartnerCast - Blueprint Delivered Series - High Fidelity Blueprint | Pega
- Achieving a high-fidelity Blueprint
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?