Inform import choices with business-design evidence
The import journey presents choices about how the selected design should contribute to the application foundation. Available choices vary by application context and asset type. The Solution Designer does not determine the technical import choice; the Solution Designer makes the business purpose, shared value, meaningful variation, dependencies, and delivery timing clear enough for the Solution Builder to evaluate the choices that are available.
Tip: Start with what the outcome needs each selected item to contribute. Use business evidence to distinguish established value, meaningful specialization, new value from Blueprint, and design for a later increment.
Understand how selected design can contribute
Import choices are best evaluated by asking what each selected Blueprint item must contribute to the application foundation and what evidence supports that contribution.
| Import choice | When to consider it | What import establishes | Business-design evidence to provide |
|---|---|---|---|
| From Blueprint | When the business objective requires new application content based on the selected Blueprint design. | Creates supported application content from the selected Blueprint item and its connected design. | Why the Blueprint design is the right source for the objective; which connected design must progress; what must remain recognizable in Authoring. |
| Use existing | When established application capability already satisfies the business objective for the selected Blueprint item. | Does not create a separate asset from the Blueprint item. Supported references are directed to the selected existing application asset. | Why the existing asset serves the same business purpose; which references depend on it; whether meaning, access, ownership, and operating assumptions align. |
| From Blueprint with inherited assets | When the objective requires new Blueprint-derived content that should inherit from established application capability. | Creates new application content from Blueprint and establishes inheritance from the selected existing asset. | What value should be inherited; what must be specialized for this outcome; which Blueprint behavior or established behavior should provide the starting point. |
| Do not build | When the selected item should not progress in the current import because it is outside the objective or increment. | Defers the item. Any effect on selected dependencies must be reviewed before import decisions are finalized. | Why the item is outside the current objective or increment; whether the selected outcome remains coherent without it; which dependency risks must be resolved. |
Dependency check: Do not build. “Do not build” is not an isolated postponement when another selected item depends on the deferred design. Before using this choice, trace which selected Case Types, Views, or data relationships reference the item. Confirm with the Solution Builder how import will treat those references and whether the current outcome will remain coherent.
Determine the Case Lifecycle starting point
When a Case Type is created From Blueprint with inherited assets, inheritance and lifecycle source are separate decisions. The new Case Type inherits from the selected existing class in either case, but the Copy Lifecycle choice determines which Case Lifecycle provides the starting point.
| Copy Lifecycle selection | Starting point established by import | Solution Designer question |
|---|---|---|
| Not selected | The Blueprint Workflow, supported Views, and Blueprint Case Data Model provide the starting point while the new Case Type inherits established capability. | Does the agreed Blueprint Workflow best represent the intended business progression? |
| Selected | The Blueprint Case Data Model is imported, while the Case Type Rule is copied from the inherited Case Type and its lifecycle becomes the starting point. | Does the established lifecycle better represent the intended progression, and is the resulting difference from Blueprint understood and accepted? |
The Solution Designer explains which progression best represents the agreed outcome, what established behavior provides value, what variation the new outcome requires, and what stakeholders must continue to recognize. The Solution Builder determines the technical implementation.
Tip: Start the working Case from the agreed Blueprint Workflow, the established Workflow, or a Blueprint Workflow supported by inherited capability, and document the business reason for the selected starting point.
Identify established capability that may contribute
Import choices become meaningful when the team understands what business value each selected item must contribute. For U+ Travel, Customer information, Weather Safety Eligibility, Customer lookup, and Guardian Consent each provide a reason to investigate established capability at the appropriate design level.
Similarity provides a reason to investigate. The team establishes the shared business purpose and locates where that value resides before deciding whether a complete design or a more focused capability should contribute.
Locate the common business value
Shared business purpose may reside at different levels of the design. Locating that value helps the Solution Designer explain whether an existing Case Type, Data Object, Business Rule, integration, Persona, or focused capability could contribute.
| If the shared value is... | Consider established capability at the level of... | U+ Travel example |
|---|---|---|
| A complete business outcome and journey | Case Type | Guardian Consent, where its complete outcome and independent journey are shared. |
| A stable policy or decision basis | Business Rule | Weather Safety Eligibility. |
| Reusable business data | Data Object | Customer identity and contact data. |
| Shared access to an external capability | Integration | Customer lookup. |
| A stable participant responsibility | Persona | A participant responsibility used consistently across outcomes. |
The following figure shows how case types, business rules, data objects, integrations, and personas are used to represent distinct aspects of a business solution:
Use the complete Case Type only where the complete business outcome and journey are shared. Where the common purpose belongs to a more focused capability, keep the shared boundary at that level and preserve the surrounding design that remains specific to Tour Booking.
Tip: Use the value that is genuinely shared, at the level where it is shared. Preserve the surrounding design that remains specific to the current outcome.
Distinguish shared, specialized, and Case-specific value
In the U+ Travel scenario, Tour Booking needs trusted Customer data to identify the customer and use reliable contact information. An established Customer capability may already provide identity and contact data from an authoritative source.
Tour Booking also needs travel-specific information, temporary selections, and data describing one booking. The shared boundary should include only the Customer data that retains the same business meaning across outcomes.
| Shared and unchanged | Specialized for travel | Specific to one booking |
|---|---|---|
| Customer identity and contact data from the authoritative source. | Selected travel data or preferences with a stable travel-specific meaning. | Temporary choices, booking selections, and Case state. |
This distinction provides the business evidence for the import evaluation. Shared Customer data may support Use existing. A shared Customer basis with meaningful travel-specific variation may support From Blueprint with inherited assets. Booking-specific data remains with Tour Booking.
Confirm that established value serves the same purpose
The Solution Designer and Solution Builder compare the established Customer capability with the purpose Tour Booking needs it to fulfil. They evaluate both alignment and meaningful difference before deciding how the Blueprint item should contribute during import by asking:
- What business purpose is shared?
- Does the established capability have the same business meaning?
- What can the current outcome use unchanged?
- What variation is meaningful to the current outcome?
- What remains specific to one Case?
- Are ownership, authoritative source, access, and operating assumptions compatible?
- How would a change to the shared capability affect other consumers?
- Does the value of consistency justify the dependency created by sharing?
The following figure shows the questions used to evaluate whether an established capability should be reused, extended, or differentiated to support a new business outcome:
The import choice is strongest when the team can explain not only what was selected, but why that choice preserves the business objective, respects established capability and keeps the connected outcome coherent.
Tip: Make the alignment and the meaningful differences equally clear. The conclusion provides the business evidence the Solution Builder needs to evaluate the appropriate import choice.
Use the evidence to inform the import choice
Important limitation: Reuse is not synchronization. Selecting Use existing redirects supported references to an established application asset; it does not synchronize that asset with the corresponding Blueprint design. Differences in Fields, property names, Case Lifecycle, Views, or Persona access still require evaluation and, where appropriate, changes in Blueprint or Pega Infinity. The Solution Designer makes the intended business meaning and identified differences explicit; the Solution Builder determines how required application changes are implemented.
The evidence gives each import choice a practical business meaning. The Solution Designer makes the purpose, shared basis, variation, dependencies, and delivery timing visible. The Solution Builder combines that evidence with technical and architectural judgment.
| Evidence established | Import choice it can support |
|---|---|
| The Blueprint design represents the required outcome or capability, and suitable established value is unavailable. | From Blueprint |
| Established capability serves the required purpose unchanged, and the import context supports directing the Blueprint item to it. | Use existing |
| Established capability provides a sound shared basis, and the current outcome requires meaningful specialization. | From Blueprint with inherited assets |
| The item belongs to a later outcome, or another material decision must be resolved before it progresses. | Do not build |
Tip: Define what the outcome requires the item to contribute, and use evidence to support the Solution Builder’s import choice.
Shape new value for credible reuse
Where suitable established capability is unavailable, shape new value around the current business need. Broaden the design boundary only where a stable shared purpose and a credible consumer are established.
The right import choice depends on whether the selected item should create new value, use established capability, inherit from it, or wait for a later increment. It should preserve the business objective, use established capability appropriately, and keep the outcome coherent.
Tip: Design new value for reuse where a stable shared purpose and credible consumer exist. Keep the current outcome clear where wider use remains uncertain.
Make the reuse rationale visible
The reuse rationale makes clear where shared value ends and outcome-specific design begins. Together, this evidence gives the Solution Builder a clear design story: what is shared, why it is shared, and where the current outcome needs something different.
The Solution Builder should not need to infer this reasoning during import. Blueprint should already make the shared purpose, variation, ownership, source information, and affected consumers visible.
Review the reuse rationale by considering:
- What is shared and where does that value reside?
- Why is the value shared?
- Which outcomes need it?
- What can remain unchanged?
- What needs to vary?
- What remains specific?
- How does sharing affect other consumers?
- What must the Solution Builder still evaluate?
The following figure shows the questions used to evaluate whether a capability should be shared across outcomes while preserving business intent, accountability, and implementation flexibility:
In the U+ Travel example, Blueprint should make clear the business meaning shared across outcomes, the established Customer information being considered, and the authoritative source. It should also distinguish the information Tour Booking can use unchanged from any travel-specific specialization and the information that remains specific to one booking.
Preserve this reasoning through the relevant design, relationships, source information, descriptions, and Notes in Blueprint. Keep the rationale beside the design it explains rather than creating a separate reuse inventory.
Tip: The reasoning is sufficient when the team can explain what is shared, why it is shared, what needs to vary, how sharing affects other consumers, and what the Solution Builder still needs to evaluate.
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?