I have a question regarding the Blueprint import process.
When I import a Blueprint into the Pega platform, all the generated rules are saved in a branch of the production application.
After importing the Blueprint and creating the required rulesets and the development application, what would be the recommended and best-practice procedure to move or merge the rules from the production branch into the development application?
We want to ensure we follow the correct approach from a governance and deployment perspective.
First, I like to clarify that when you say Production Application it is the Target application on development environment? I mean because we shall import the blueprint on Development environment.
From my perspective, once the Blueprint is imported into the target application, the recommended approach is to treat the generated rules like any other development artifact and follow standard branch‑based best practices.
Specifically:
After the Blueprint import, add this branch to the development application where further refinement, extension, and validation will occur.
At this stage, you can remove the branch reference from the target application (without deleting the rules themselves), ensuring the target app remains stable and clean.
From there, teams can continue working on the Blueprint‑generated rules in the development application, iterating as needed to reach high‑fidelity alignment with business requirements. This includes refining case life cycles, data models, views, and integrations beyond what Blueprint initially generates.
Once the changes are fully implemented, tested, and validated, the branch can be merged back into the target application, following the same governance, testing, and deployment standards used for any other development work.
In summary, Blueprint import is best viewed as an accelerator for initial design and structure, not a shortcut around established development practices. Managing Blueprint rules through branches and merges ensures traceability, quality, and consistency across environments.
Thank you for the clarification — yes, I was indeed referring to the target application.
I also noticed that in the class structure generated during the Blueprint import, for the Integration layer classes, the system creates the class under Org-App-Data instead of Org-App-Int. I wanted to confirm whether this is expected behavior or if it requires any adjustment for following our standard layering conventions.
Yes, this is expected behavior with Blueprint import.
During the Blueprint import, the system creates Data classes under Org-App-Data, even for objects that conceptually represent integrations. This is intentional and aligns with the role Blueprint plays in the lifecycle.
Blueprint focuses on establishing a design‑time starting point to support:
Case structure
Data model
View/UI pre‑visualization
End‑to‑end flow understanding
At this stage, Blueprint generates data objects only, primarily to support UI rendering, relationships, and case logic validation. It does not attempt to model the full integration architecture.
This is different from using the Integration wizard, which explicitly creates:
Org-App-Int-* classes to represent the external system model
Separate Data classes to map external structures into the internal Pega data model
With Blueprint, the assumption is that teams will evolve the application after import. As part of that evolution, it is expected that architects:
Introduce proper Org-App-Int-* classes when implementing real integrations
Refactor or extend the generated Data classes as needed
Apply standard layering and integration best practices during implementation
So in short, Blueprint intentionally creates a simplified data-centric model to accelerate design and validation, with the expectation that some rework and refinement will occur once development moves beyond Blueprint and into full implementation.
I’m now encountering another issue: after importing the Blueprint into the target application and creating Dev and Test applications, all of them show the warning “Unlock application ruleset to update routing table.”
The rulesets in the stack are already unlocked, but the platform still seems unable to detect a writable ruleset for the Routing Table.