New Case type with Constellation Framework built on top of existing UIKit application

User Experience
1

We have an application running on UI Kit for the past 9 years, with 8–9 case types currently implemented. The current version is Pega Infinity 25.1.2.
Now, we have a new use case with high complexity in terms of backend logic, involving delegated tables and data sourced from interfaces. The business is interested in using the Constellation framework for this new case type, along with Blueprint for closer collaboration during the development cycle.
Below are some must-haves for this new case type:

The new Constellation case type should be able to trigger an existing UI Kit case type as a standalone case.
There should be a possibility of reporting by combining records from both the existing UI Kit case type and the new Constellation case type.

What is the recommended setup for this?
Option 1:
Create a new Constellation application built on top of the existing legacy UI Kit application, and create the new case type within this Constellation application.
To satisfy the above must-haves, ideally the work data for the new case type should be stored in the built-on UI Kit application. Is this achievable?
Alternatively, is it recommended to change the database table mapping of the Constellation implementation class to point to the built-on UI Kit application’s work table?
Option 2:
Create a new application using the Constellation framework and build it on top of the old legacy UI Kit application. Develop the new case type in this new application layer and store its data in a separate work table from the built-on application’s work table.
In this scenario, requirement 1 can still be met by creating the UI Kit case using a REST API, which we have already implemented to trigger the case type. However, how can we satisfy the joint reporting requirement between the old UI Kit application and the new Constellation application?

2

@VirendraSawant Are you in the User Experience Expert Circle? I would like to move this under that area, so it can be found with other Constellation questions. However, if you are not a member you won’t be able to respond (until you join), so don’t want to just move on you.

Please let me know if you join and i’ll move.

image

3

Hi,

one clarification. Going forward what is your expectation in regards to target application.

Two options possible:

  • stick to Traditional app and blend in new case Type
  • Constellation app will be the default app going forward and you “reuse” case types from Traditional UI
4

Hello Marc,

I have joined the Ux expert circle, please do as you deem fit :slight_smile:

Thank you!

5

Hello Kamil,

As the architect for this application over the past 8+ years, my strong preference is that we move toward Constellation in the cleanest and most sustainable way possible. I would like to avoid any hybrid or partially adopted approach where we compromise on capabilities due to incomplete migration.

From my understanding, Constellation represents the strategic direction recommended by Pega. In line with that, we have a long-term vision to migrate the remaining 8–9 case types as well into Constellation.

That said, in the interim, we should not block business needs. There are two critical capabilities we must address:

1 - Triggering UI-Kit Case Types from Constellation
The new Constellation case type should be able to trigger an existing UI-Kit-based case type as a standalone case.

I believe this can be handled by reusing an existing REST API to initiate UI-Kit case types.
This approach should help us maintain separation while enabling interoperability without introducing technical debt.

2 - Unified Reporting Across UI-Kit and Constellation
We need the ability to generate reports that combine records from both existing UI-Kit case types and new Constellation case types.

If there is a recommended workaround within Pega (e.g., reporting strategies, data pages, or externalized reporting), it would be highly appreciated.
As part of our roadmap, we are planning to stream case updates via Kafka into an analytical platform (Snowflake), which will eventually provide a unified reporting layer.
However, until that pipeline is fully operational, we need an interim solution for combined visibility.

Any approach we adopt for the new Constellation case type should be future-proof and aligned with Pega’s evolving architecture. We want to ensure consistency so that what we implement now continues to scale as we migrate additional case types.

For context, this is for the Siemens AG Order Management application.

Looking forward to your guidance on the best approach, particularly for the reporting use case.

Thank you!

Best regards,
Virendra

6

First of all, great initiative on moving towards Constellation. This is absolutely the right direction :+1:

Based on what you’ve described, there are a few options you can consider depending on how tightly you want UI-Kit and Constellation to work together during the transition.

  • Process Fabric - If you’re aiming for a more unified experience, this helps bring everything together, like a single worklist, ability to access cases across applications, etc. It’s quite powerful for coexistence scenarios, especially when you have multiple apps (UI-Kit + Constellation) and want to minimize context switching. Just keep in mind this is a licensed feature.
  • Remote Case Types - Constellation case can trigger or interact with a UI-Kit case without tightly coupling the two. It helps you maintain separation while still enabling interoperability, which is important if you’re trying to avoid long-term technical debt.
  • Application blending - This allows you to gradually introduce Constellation while still leveraging existing UI-Kit case types.
  • REST/DX API - invoking APIs from your Constellation layer can be a very clean integration pattern.

Depending up on your business requirement, you can choose the correct option that fits your rquirements.

7

First of all,
thank you for well structured questions.
I have asked other collagues and experts to chime in.

In the mean time please take a look on recording of UX EC webinar on modernization topic: Transform Your Applications: Master the Constellation Modernization Assistant Tool | Pega

There are also corresponding assets like FAQ attached. Hope this will be helpfull as starter.

8

My preference would be blending UI architecture (mentioned in @RameshSangili’s reply).

However, you have talked about using API’s to trigger UI-Kit case types. I would suggest reading @Will_Cho’s Constellation 101 on the topic. It may help with your decision and guide your implementation (if you go that path)

9

I like how you are thinking of moving the whole application to the latest platform architecture. You are better off starting on the blended UI approach. Blended UI is the bridge to incrementally move to constellation.

Are you facing any specific challenges in creating the blended mode? Reporting, case creation should work in that approach.

Creating the traditional case from constellation case type should be straight forward with the create case smart shape (REST API may not even be needed).

10

Hello Ramesh,

Thanks for your suggestions. After giving it much thought around restrictions and making business understand advantages of constellation, it was decided that we create this new case type in constellation. The future vision being that when we migrate the rest of 8 case types from UI KIT to constellation all the non UI related rules can be easily reused from UI KIT app to the new migrated case types in constellation app. The new setup for enabling this which i have in mind is that we create new constellation app built on top of UI KIt application with constellation inheriting all the code from old UI Kit app.

My primary question here is with this setup can we some how use the old work table in UI KIT to store the new constellation case data instead of new work table on constellation app?

Process Fabric - We do not have requirement for single worklist. And i feel its better to have a clean start in new constellation app

Remote Case Types - Once we built constellation on top of UI Kit we will explore this option in case we want to trigger UI Kit case type from constellation case type.

Application blending - Can consider this but this will require maybe some more effort (and will be wasted when we fully migrate old ui kit cases to constellation?) and will be hybrid in nature? Want to leverage all features of constellation - will this be still possible in application blending?

REST/DX API - Already in consideration.

11

Thanks Kamil - It would be really nice to hear from the experts, please let me know in case you have any suggestion from them yet - also re-pasting response to Ramesh for your reference -

After giving it much thought around restrictions and making business understand advantages of constellation, it was decided that we create this new case type in constellation. The future vision being that when we migrate the rest of 8 case types from UI KIT to constellation all the non UI related rules can be easily reused from UI KIT app to the new migrated case types in constellation app. The new setup for enabling this which i have in mind is that we create new constellation app built on top of UI KIt application with constellation inheriting all the code from old UI Kit app.

My primary question here is with this setup can we some how use the old work table in UI KIT to store the new constellation case data instead of new work table on constellation app?

Process Fabric - We do not have requirement for single worklist. And i feel its better to have a clean start in new constellation app

Remote Case Types - Once we built constellation on top of UI Kit we will explore this option in case we want to trigger UI Kit case type from constellation case type.

Application blending - Can consider this but this will require maybe some more effort (and will be wasted when we fully migrate old ui kit cases to constellation?) and will be hybrid in nature? Want to leverage all features of constellation - will this be still possible in application blending?

REST/DX API - Already in consideration.

12

Hi Srinivas,

Will using blended method not have efforts which later will not be useful in case we migrate all the 8 case types from UI Kit application to new constellation app? Just want to avoid rework/wasted efforts if the end goal is migrating all the case types to new constellation app. Please see reply to Ramesh for more clarity :slight_smile: