The reuse decision: Inherit, reuse, build new, or defer

Solution Builders evaluate each asset specified in the Blueprint to determine its implementation. These choices apply to every import, whether the application is the first one or part of a larger architecture, and they establish the foundation for the build and future growth of the application.

Getting these decisions right at import is much less expensive than correcting them after the application is in production.

How reuse works during import depends on the context of the application you are building. Whether you are creating a new application, extending an existing one, or building on other applications influences the implementation choices available to you. During import, Solution Builders review each asset defined in the Blueprint and decide how to implement it, based on what already exists in the enterprise and what needs to be introduced now. In some situations, all implementation options are available; in others, the choices are more limited. The goal is not to apply the same option everywhere, but to make deliberate decisions that reflect the context and starting point of the application.

Before selecting an implementation path for any asset, perform a lightweight reuse scan. Review the design against the existing enterprise application landscape to identify available connectors, enterprise data objects, or case types that you can inherit or reuse.

The four implementation options are:

• Inherit: Extend an existing class to add fields or behaviors that are specific to this application. Use the inherit path when an enterprise-standard asset exists and the application needs to tailor it while remaining compliant with enterprise standards and fully upgradeable. Inherit is the preferred path when a mature enterprise model is available.
• Reuse: Reference an existing asset exactly as it is, with no modification. Use the reuse path when the asset is already proven and stable, and does not require any change for this implementation. Reuse avoids duplication and supports consistency across the enterprise.
• Build New: Create a new asset when no suitable existing asset is available. When you build new, evaluate whether the new asset can become part of a reusable module for future implementations. Use broad naming conventions for future use. For example, name the object Vehicle, not Car, if the asset eventually needs to accommodate more than one vehicle type.
• Do Not Build (Defer): Skip the asset during the current import. You can import the asset during a later extension phase. Deferring does not prevent the application from being created; it scopes the current delivery to what is ready.

In Pega Infinity™ '25, you can use the Reuse Library in App Studio to create shell Rules for reusable Rules, such as When Rules, during Case design. Solution Builders can populate the underlying logic separately. This pattern supports collaborative authoring and reduces the risk of duplicating existing work.

Blueprint Delivered™ treats reuse as a structural and repeatable decision made during import. Solution Builders select from the defined implementation options at a point where enterprise context and long-term impact are easiest to assess.

• Creating a new application from Blueprint: Learn how to import a Blueprint to create a new Pega application and establish a clean starting point for implementation.

• Extending an existing application with inheritance: See how to extend an existing application by inheriting from a Blueprint, preserving shared assets while supporting application‑specific behavior.

• Incrementally extending with defined workflows: Understand how to incrementally apply Blueprint‑defined workflows to an existing application to introduce change in controlled stages.

• Creating a new application built on existing assets: Explore how to create a new application that reuses established assets, accelerating delivery while maintaining architectural consistency.

Check your knowledge with the following interaction: