We are currently driving the adoption of Pega Blueprint integrated directly with Pega Studio as part of our strategy to accelerate delivery, enable vibe coding, and align with Pega’s official recommendation around Low‑Code Enterprise Development (LCED).
During a recent technical validation, we identified some structural gaps in the Blueprint import process that make it difficult to use Blueprint as a fully reusable, LCED‑ready artifact when initializing or extending an application in Pega Studio.
More specifically, after importing a Blueprint into an LCED application, we observed the following limitations:
Misalignment between Blueprint constructs and LCED Features – tasks defined in Blueprint are not imported in a way that maps naturally to reusable application Features.
Flows are imported as Screen Flows instead of Standard Flows, requiring manual rework to make them reusable and feature‑aligned.
Stage‑based process structure is flattened or partially lost during import, which impacts orchestration and reuse at the feature level.
Personas and associated roles are not migrated in a reusable, LCED‑aligned way, requiring deletion and recreation of security artifacts.
As a result, Blueprint currently works well for Case Type creation and the data model, but does not fully support business processes that are expected to be delivered as reusable Features in an LCED application. This introduces technical rework (removal and recreation of flows, processes, roles, and security configuration) after import.
Our goal is to leverage Blueprint as a native, production‑quality accelerator for LCED, without post‑import reprocessing in Pega Studio, in line with the vision that has been shared by Pega leadership around Blueprint‑driven development.
We would appreciate guidance from the community or Pega product experts on:
Whether these gaps represent current product limitations vs. expected behavior
If there are recommended patterns or configurations to better align Blueprint import with LCED Features
Or if this is an area already covered or planned in the Blueprint / LCED roadmap
Any insights or experiences would be greatly appreciated.
Thanks for the feedback on this. I would like to share the feedback with our product team and it would be helpful to get a little more detail about specific outcomes that you are looking to see.
I’ve seen a few different configuration approaches with LCED, for example, I know of an implementation that created a case type with every potential step and then used logic to suppress/enable steps based on regional settings. I have also implemented reusable capabilities by creating flows in Work-Cover- in modular applications so that those utility flows are available for use for any application and any case type.
What are some specific things you want to do in blueprint and then how do you want to see them translated post-import?
In regard to flows getting created as screen flows, that is true of the first stage, but after that, they are usually created as normal flows (at least that is what happened with my last import).
Thanks Chris, this is very helpful context and aligns with some of the patterns we have also explored with LCED.
To clarify our expectation, the main gap we are seeing is not at the level of case type definition or optional step configuration, but at the reusability model when importing Blueprint into an existing LCED application.
In our target architecture, we are structuring business capabilities around reusable Features, with flows and processes designed to be shared across case types and applications (for example, using modular layers like Work-Cover or similar shared artifacts).
The challenge we are encountering is that during Blueprint import:
Existing reusable Features / flows are not recognized or reused
Instead, new flows are generated (often as Screen Flows initially), requiring us to delete and recreate them as reusable assets
This breaks the LCED principle of feature-driven reuse and modularity, and introduces additional technical rework after import
To describe the desired behavior more concretely:
We would expect Blueprint import to behave similarly to how data objects are handled, where the platform allows you to:
Create a new artifact or
Map to an existing one
Applying this same concept to Features and flows would allow:
Mapping Blueprint-defined processes to existing reusable Features
Preserving modular flow design (Standard Flows vs Screen Flows)
Avoiding the need to remove and recreate rules post-import
Ultimately, our goal is to use Blueprint not only as a design accelerator, but as a true LCED-aligned starting point, where imported artifacts can immediately fit into an existing feature-based architecture without rework.
It would be great to understand:
Whether this type of Feature-level mapping/reuse is something supported today (with a specific pattern), or
If this is an area that is being considered as part of the Blueprint → LCED evolution roadmap
Thanks again for the guidance — this is a key topic for us as we scale Blueprint adoption in a reusable, enterprise-grade LCED model.
At this point in time, your blueprint is not aware of the flows/features you have in your enterprise (in modules for example). The team is looking to provide ways of making your reusable content available during design time.
Until then, the best advise is to can give is for every place you want to use a feature in your case flow, to start a new process in the stage you want to use the feature and add a utility shape and name that as the feature and provide some details in the notes. Like the below picture.
Then after import, you can easily replace the utility by calling the flow for that feature. The story that gets created has the information from the notes so the dev team has the information of what change is required. Changing to the feature is quick and easy.
This way you can capture the business intent in blueprint and show that through the preview in Blueprint.
The reason for creating a separate process for every feature is that it gives you more flexibility; its easier to move around and you can apply pre-conditions to determine if your context will run this feature or not.
