Blueprint import

Before import, confirm that the Blueprint is ready to become the application foundation. A ready Blueprint provides enough detail for the team to import, validate, and begin authoring without reinterpreting the design.

A Blueprint is ready to import when the team can confirm that:

• The business outcome and application scope are clear.
• The Case Types, workflows, Data Objects, and Personas are defined well enough to support import.
• The team has reviewed the Blueprint for accuracy and completeness.
• Reuse opportunities have been considered before import.
• Known integration, data, and implementation considerations are documented at the right level for the import decision.

During import, Solution Builders make decisions for Blueprint containers, also called artifacts. The primary containers are Case Types, Data Objects, and Personas. Each container represents a business-level design element in Blueprint and becomes a unit of decision-making during import.

The available options depend on the Blueprint content, the application context, and the import options selected:

• A Case Type container can create or connect to Case-related implementation assets, including the Case Type, Lifecycle structure, Stages, Steps, and related Case configuration.
• A Data Object container can create or connect to data-related implementation assets, including Data Objects, data structure, fields, and related data configuration.
• A Persona container can create role-related application assets that support access and user participation in the application.

The import creates the supported Rules and sample data from the Blueprint file based on the selected scope and options. The value of AI is primarily in helping create and refine the Blueprint; import produces a generated application foundation that the team must validate.

Import options depend on both the type of container and the application context. Before selecting options for individual containers, decide whether the Blueprint will be used to:

• Create a new application.
• Create a new application that is built on an existing application.
• Extend an existing application.

These choices affect which options are available during import and where the resulting assets fit in the application structure.

Generating responseCopilot said: When creating an application from Blueprint, Solution Builders can specify the application name and select a built on application when needed. Before generating the application, they can use Customize build to review and adjust the selected Case Types, Data Objects, and Personas. For a new application, Case Types can be built from Blueprint, inherited from a built-on application when one is selected, or omitted. Data Objects can be built from Blueprint, inherited from a built-on application, linked to an existing Data Object when a built-on application is selected, or omitted. Personas can be built from Blueprint or omitted.

When extending an existing application, Solution Builders upload or select a Blueprint and then decide how each container will be handled. Case Types can be built from Blueprint, built from Blueprint with inherited assets, mapped to an existing Case Type when available, or omitted. Data Objects can be built from Blueprint, built from Blueprint with inherited assets, linked to an existing Data Object, or omitted. Personas can be built from Blueprint or omitted.

A single Blueprint does not require every asset to be built into one application layer. Depending on the implementation strategy, the team can create new assets, extend existing assets, or connect to assets in built-on applications. This helps teams use one Blueprint to support a layered application structure instead of treating the Blueprint as a one-app-only import.

The following image shows the process for selecting an implementation path:

Import options by container

The goal during import is not to select the same option for every container. The goal is to choose the option that fits the container type, the application context, and the reuse strategy. The following table describes the import options available for each container type:

For Case Types, From Blueprint with inherited assets creates a new Case Type that inherits from an existing Case Type. If the team selects Copy Lifecycle from inherited Case Type, the Case Type Rule is cloned from the inherited Case Type. If the team does not select that option, the Case Type Rule is built from the Blueprint. Use this decision deliberately: the team will know whether the Blueprint lifecycle or the inherited lifecycle will drive the new implementation.

For Data Objects, From Blueprint with inherited assets creates a new Data Object that inherits assets from an existing Data Object.

Do Not Build and Use Existing

Do Not Build and Use Existing can appear similar because neither option creates a new asset from the selected Blueprint item. However, they represent different decisions.

Use Do Not Build when the Blueprint container is outside the current delivery scope or must not be created during this import. The team might use this option when importing one outcome or one Case Type at a time.

Use Use Existing when the required asset already exists in the current application or built on application stack. This option connects the imported assets to the existing asset instead of creating a duplicate. For Data Objects, Use Existing links the Data Object to the built-on or existing application and reuses assets from that Data Object without creating its own class in the new or extended application.

Use Existing does not mean that the existing asset stays synchronized with the Blueprint. It means the import uses the selected existing asset instead of generating a new one for that Blueprint container.

Before submitting an import, use the review screen to confirm that the generated application structure matches the intended implementation strategy. The review step gives Solution Builders control over the structure of the new application and the assets being created or connected.

For a new application, review the application settings, organization settings, class layers, Case classes, and Data classes. Confirm that the application name, application ID, version, base language, organization, division, unit, class layers, Case classes, and Data classes match the intended structure.

For an existing application import, review the Case classes and Data classes before submitting. Confirm that the selected import options produce the expected class structure and inheritance paths.

This review is especially important when a Blueprint is used to create or extend assets across multiple application layers. The team must confirm that the Blueprint-generated foundation supports the intended layer structure before the import branch is validated and merged.

Blueprint import precedes the creation of the application foundation based on the selected containers and import options. Depending on the Blueprint and the implementation context, import can create or connect to Case Types, Data Objects, Personas, application structure, and related configuration.

All generated assets, except Access Roles, are created in a branch. After the team validates the generated assests, the import branch must be merged before feature development begins. Do not perform feature development in the import branch.

After importing a Blueprint, validate that the generated assets match the Blueprint design. Run the imported Case in the development environment to confirm that the workflow runs as designed, using generated or simulated data when appropriate.

During validation, confirm whether:

• The generated Case Types match the Blueprint design.
• The generated workflows reflect the intended Stages and Steps.
• The Data Objects and Personas are present and accurate.
• Generated Views, routing details, and business context align with the Blueprint where applicable.
• Reuse, inherit, build-new, use-existing, or do-not-build decisions produced the expected application structure.
• Any missing or incorrect details are identified for follow-up.

If the import result is structurally incorrect, the team might need to discard the import branch, correct the Blueprint or import decisions, and re-import.

Validation and Authoring can reveal new information. Blueprint Delivered does not require teams to freeze thinking after the first import. The goal is to handle new insight deliberately.

Apply the change in Blueprint when it affects the intended business outcome, Case Lifecycle, Persona behavior, workflow structure, major data assumptions, or other stakeholder-visible behavior. Use the improved Blueprint for the next import so future generated assets continue to reflect the validated design.

Make the change directly in Pega Platform when it is an implementation refinement that supports the approved design without changing the intended outcome.

If a Case Type needs a structural change, update the structure in Blueprint and make the corresponding change in Pega Infinity Studio so the working application remains aligned with the source design.

Check your knowledge with the following interaction: