Conversation
Ernst & Young
ES
Last activity: 18 Feb 2026 15:07 EST
Moving rules from production branch after Blueprint import
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.
Thank you in advance for your guidance.
Pegasystems Inc.
US
Ernst & Young
ES
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.
Thank you again for your guidance.
Pegasystems Inc.
US
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:
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.
Ernst & Young
ES
Hi, thank you for your response.
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.
Could you advise what might be causing this?
Pegasystems Inc.
US
Hi @HalynaK2,
Did you switched on your "Brach development preferences"? If not, follow these steps,
- Click "Toggle branch development" icon
- Turn on Branch development
- Select your development branch.
https://docs.pega.com/bundle/platform/page/platform/app-dev/setting-bra…
Hi @HalynaK2,
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:
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.
Hi @HalynaK2,
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:
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.
References:
https://academy.pega.com/topic/best-practices-branch-based-development/v1
https://academy.pega.com/topic/application-development-best-practices/v1?
https://docs.pega.com/bundle/platform/page/platform/app-dev/branches-br…