There is already a lot of content explaining what Pega Blueprint can do. I wanted to look at it from a slightly different angle.
I wanted to see what happens when you actually take a Blueprint all the way through application generation in Pega Infinity, run what gets created, and then inspect the generated rules and class structure in Dev Studio.
For this exercise, I used a healthcare payer customer-service scenario and followed the process from initial Blueprint creation through runtime validation:
Business idea → Blueprint → AI-assisted refinement → Preview → Build from Blueprint → generated Infinity ’26 application → runtime testing → Dev Studio inspection
The video below captures the journey step by step.
Watch the end-to-end walkthrough
This was not intended to become a production-ready healthcare application. The goal was to understand what Blueprint gives you out of the box, what the Infinity ’26 generation process actually creates, and where normal Pega architecture and development work starts again.
Starting with the Blueprint
I started with:
Healthcare → Healthcare Insurance (Payer) → Customer Service
and described a member-service application supporting common payer scenarios such as claims, benefits, providers, authorizations and profile servicing.
Blueprint generated a fairly broad first cut: roughly 25 workflows, along with supporting data objects, personas and customer-service capabilities.
I did not want to import that entire scope just because it had been generated.
Instead, I used the Blueprint AI Assistant to challenge the workflow list and reduce it to a smaller starting point.
The final set I retained was:
Claims Inquiry, View Benefits, Find Provider, Authorization Inquiry, Order ID Card, Update Contact Profile, Claims Research and Provider Follow Up.
This was one of the first things I found useful about Blueprint. The first generation was not really the final design. It became a starting point for narrowing the scope and deciding what should actually be part of the first implementation.
Using Preview before generating the application
Before moving into Infinity, I spent some time in Blueprint Preview.
Claims Inquiry was particularly useful because it touched several parts of the proposed application: member selection, claims, follow-up processing and resolution.
I also walked through View Benefits, where the generated experience included information such as copayment, deductible, coinsurance, authorization requirements and benefit utilization.
That gave me a much better feel for the application than simply reading the workflow definition.
I also tried Knowledge Buddy in the generated experience. The feature was present, but it did not have enough grounded content to answer one of the detailed benefit questions I asked.
That was a good reminder that enabling a capability in a design and having the enterprise content/configuration behind that capability are two different things.
Moving into Infinity ’26
The more interesting part started when I exported the Blueprint and used Build from a Blueprint in Pega Infinity ’26.
The wizard walked through case types, data objects, personas, features and the final review rather than treating the Blueprint as a simple one-click import.
One thing surfaced immediately.
The Blueprint had been designed with a Customer Service for Healthcare / Constellation foundation in mind, while the environment I was using did not have that complete product stack available (community edition).
The wizard warned that the underlying application did not match the application for which the Blueprint had originally been designed, and that functionality could therefore be missing.
I continued because this was a learning exercise and I wanted to see what Infinity would generate anyway.
Later in the wizard, the same mismatch showed up again when some Blueprint features were excluded from the build because of the selected underlying application.
That is something I did not appreciate fully until I ran the import myself: the target application’s foundation affects how faithfully the Blueprint can be materialized.
What was created
The completed build reported:
8 Case Types
11 Data Objects
5 Personas
3 Channels
That sounds fairly small until you open the generated application.
Underneath those high-level objects, Infinity had generated case lifecycles, views, data classes, properties, references, navigation, rulesets, sample data, an implementation plan and a development branch.
The generated branch contained well over a thousand rules/artifacts.
That was the point where the experiment became more interesting for me. Blueprint was no longer just a design artifact. The business design had turned into real Pega implementation assets.
The Implementation Plan was worth looking at
One output I had not really thought much about before doing this exercise was the generated Implementation Plan.
In my application it showed:
107 To Do
27 In Review
0 In Progress
0 Done
The backlog included items such as workflow-step configuration and data-model work.
I actually liked this because it made the state of the generated application fairly explicit.
The application had been created, but Pega was not pretending that the implementation was finished.
There was still a visible body of work that needed attention.
Running the application exposed more than looking at the design
The most useful part of the exercise was probably running the generated application.
I opened Preview App and started a Claims Inquiry.
The Member field worked and showed generated sample members.
After selecting a member, however:
Plan had no selectable records.
Claims had no records.
Provider had no records.
At first I wondered whether the generated class mappings were incomplete.
So I went into Dev Studio and checked.
The class mappings themselves looked fine.
The difference was in the data.
Member had sample records. Policy had sample records. Several other objects, including Plan, Claim, Provider and Benefit, had zero rows.
That distinction is easy to miss when only looking at the Blueprint:
the data object can exist, its database mapping can be correct, and the runtime experience can still be empty because the supporting records or relationships have not been populated.
That was something I understood much better after actually running the case.
A second runtime issue led back to the generated process
When I proceeded in Claims Inquiry, I received:
Create Child Case: The class of the child work object is not specified
That was interesting because Claims Research and Provider Follow Up had both been generated successfully as case types.
So this was not simply a missing child case class.
The likely issue was the generated Create Child Case configuration itself, where the child work class still needed to be defined or refined.
That difference matters when troubleshooting.
Without inspecting the generated application, it would have been easy to conclude that Blueprint had simply “failed to create the child case.”
It had not.
The classes existed. The process configuration still needed work.
Looking at the generated Work classes
From there I moved into Dev Studio.
For Claims Inquiry, the generated class was:
MyOrg-MyHealth-Work-ClaimsInquiry
The class definition showed:
- Concrete class
- Class group:
MyOrg-MyHealth-Work - Pattern inheritance enabled
- Directed parent:
Work-Cover-
The case classes were mapped through the application Work persistence structure, including the shared:
pc_MyOrg_MyHealth_Work
table.
Seeing this was useful because it connected the visual case model in Blueprint to the actual Pega Work hierarchy.
The Data classes were different
I then looked at:
MyOrg-MyHealth-Data-Claim
This was also a concrete class, but the structure was different:
- Pattern inheritance enabled
- Directed parent:
Data- - No class group
pyGUIDgenerated as the key- CustomerData persistence
- Dedicated table:
pr_myorg_myhealth_data_claim
This Work-versus-Data distinction was much clearer when looking at what Blueprint actually generated than it was from the high-level application design.
The Claim object itself also contained a fairly detailed set of fields: charged amount, copay, coinsurance, deductible, admission information, diagnosis information, billing provider and authorization-related information.
More importantly, some of those were actual data references rather than duplicated text attributes.
For example, Billing Provider referenced the Provider data object.
That told me Blueprint had generated more than just screens and fields. It had created a connected application data model that could be evolved further.
The generated application still enters the normal Pega lifecycle
Once the application existed, everything started to look familiar from a normal Pega engineering perspective.
There was a development branch.
There were guardrail warnings.
There was test coverage to think about.
There were merge candidates.
There were database mappings and inheritance choices to review.
Blueprint got the application to that point much faster, but from there the usual engineering disciplines still apply.
That feels like the right model to me.
The architecture question I was left with
The generated application currently places the implementation under classes such as:
MyOrg-MyHealth-Work-*
and:
MyOrg-MyHealth-Data-*
For this exercise, that makes sense.
But after seeing the actual class structure, it raised the next question I want to explore.
Concepts such as:
Member
Claim
Provider
Plan
Benefit
Authorization
are not really unique to the MyHealth implementation.
If this were being developed as a reusable payer platform, should those classes remain application-specific?
Or should some of them sit in a reusable healthcare-payer layer, with MyHealth and individual health-plan implementations built on top of that foundation?
That is where I am planning to take the exercise next.
What I learned
Before doing this, I probably thought about Blueprint mostly as:
Prompt → Blueprint → application
After using it end-to-end, I think the process is closer to:
Explore → generate → challenge → refine → preview → build → run → inspect → improve
The most valuable findings did not come from watching the Blueprint generate.
They came afterward:
- seeing how the target application affected the import;
- reviewing generated rule warnings;
- understanding what the Implementation Plan represented;
- discovering the difference between generated data classes and populated runtime data;
- tracking a runtime child-case error back to process configuration;
- and finally seeing how the Blueprint model translated into actual Work and Data classes.
Blueprint removed a lot of blank-page work.
It did not remove the need for architecture, testing or implementation judgment.
For me, that is not a weakness. It is probably the right boundary.
My next step is to take this generated MyHealth baseline and see how it can be evolved into a reusable healthcare-payer and health-plan architecture without losing the speed and design continuity Blueprint provided.
I would be interested in hearing how others are handling this:
After importing a Blueprint, how much architecture refinement are you doing before feature development begins?