Simulation of Temporary case type implementation in Constellation

User Experience Knowledge Share
, ,
1

Hello everyone,

We recently worked on a modernization of client onboarding application which is in UI-Kit and the client had 3 key expectations:

  1. Adopt Constellation capabilities for modernization
  2. Retain certain existing workflows and UI behaviors from the traditional UI
  3. Execute this as a phased modernization, avoiding large upfront investment and minimizing business disruption

To support this “safe transition” strategy, we initiated modernization using the Constellation Migration Assistant (CMA) and started the UI remediation.

Challenge Identified

During the migration, we identified that 3 case types were implemented as temporary cases in the traditional UI.

Expected behavior:

  • On “Create Case” → no case is created immediately
  • User is shown an initial data capture screen
  • On submit:
    • Validation is performed
    • Case is created only if valid
    • Processing continues to next stage

However, in Constellation, temporary cases are not supported, which created a functional gap.

Constraints

  • The client did not want to introduce additional case types (due to licensing and contractual constraints)
  • The existing user experience had to be preserved
  • First screen patterns were similar across case types (with slight variations in fields)

Proposed Solution

We designed a hybrid approach using a custom DX component, while leveraging standard Constellation capabilities.

Solution Overview

Here is a pictorial representation of the solution,

image
image1536×1024 173 KB

1. Landing Page with Case Type Selection

  • A custom component is exposed as a landing page
  • Displays cards for each case type
  • Cards are dynamically driven by a Data Page

Each case type configuration includes:

  • Case Type Label
  • Case Class
  • Local Action (for initial data capture)
  • Icon (optional)

This ensures flexibility and easy control via configuration.

2. Dynamic Rendering via Data Page

  • Data is fetched using getDataAsync from the component
  • Backend logic (Data Transform) controls visibility using When conditions

3. Modal-based Initial Data Capture

  • On selecting a case type:
    • A modal dialog is launched using Pega’s ModalManager API
    • Modal loads a local action + view
    • View is extended at implementation layer for flexibility
    • An editable data page of work pool class is passed as parameter to component which will serve as the context for the modal

This replicates the “first screen before case creation” behavior.

4. Validation & Case Creation via DX API

  • User fills the form and submits
  • On submit:
    • UI validations are executed
    • Data is passed to DX API for case creation
  • On cancel: close the modal and do nothing

We use:

  • Implementing AllowStartingFields DT to allow required properties
  • A custom flag to indicate source = component

5. Stage Skipping Logic

  • Case types are configured as standard (non-temporary)
  • First stage includes a When condition:
    • If created via component → skip initial stage
    • Else → proceed normally

This ensures that same case type supports both:

  • Standard creation
  • Temporary-like behavior

6. Post case creation

  • Once the case is created, the newly created case Id will be returned in the response.
  • We can then choose to replace the current work area with newly created case.

Key Benefits

  • Preserves existing user experience
  • Aligns with Constellation architecture
  • Avoids introduction of additional case types
  • Can be easily extended for new case types in future
  • Highly configurable via Data Pages
  • Minimal dependency on custom component (UI-only concern)

Design Considerations

  • This approach leverages OOTB capabilities:
    • Local Actions & Views
    • DX APIs
    • ModalManager
  • The custom component primarily acts as an orchestration layer
  • Future changes to fields or behavior can be handled in Pega rules without modifying the component

Conclusion

While Constellation does not natively support temporary cases, this approach provides a practical workaround by combining:

  • UI-driven data capture
  • Controlled case creation via DX APIs
  • Conditional stage progression

This pattern can be useful for teams looking to modernize incrementally without compromising existing business flows.

Curious to hear if others have implemented similar patterns or found alternative approaches for handling temporary case behavior in Constellation.

Regards

JC

2 Likes
2

Thanks for sharing @JayachandraSiddipeta . An interesting solution and I’d like to propose a simpler one if I may? It’s funny because this came up recently in another forum.

A case that creates another case

I’ve successfully implemented this in multiple Constellation clients since 8.8. You have a case that creates your primary cases.

  1. Create case smart shape, do not select ‘child case’ (you can but it tends to confuse the UX)

    1. This can be made dynamic by using a data reference for “case type” selection at start, which has the case and class needed

  2. There is no link between the “case that creates another case” and the child cases, so they can be archived/deleted almost immediately

  3. I see you might have considered and discounted this option? “The client did not want to introduce additional case types (due to licensing and contractual constraints)”

    However, this does not need to be a limiting factor. If the client talks to their Pega account team - commercials should not dictate solution, nor make it harder to implement. In fact, if we really wanted you could create an entire app that has no cases - so this is a poor excuse for overcomplicating design.

Why I like this solution

  1. It leverages Constellation and Pega Out of the Box case design/principals
  2. You can create views for each “case type” easily and although I didn’t in the past, you probably could reuse the Views between the top and spin-off cases.
  3. No DX components
  4. Leverage case creation components
  5. Future proof, if any of the assets you are using change in future releases.

Not a criticism, more sharing successful implementations of the “case that creates another case” approach that have worked for me in the past, to provide an Out of the Box counter for the proposed solution.

Thanks again for sharing your knowledge :slight_smile:

  • I have updated this to “knowledge share” so it can be found with other useful knowledgeshares
1 Like
3

Best way to tackle potential license issues (regarding # of cases and case types) when designing your app is to talk to your account team, not to create more complex solutions. Otherwise we will end up with a very small number of very complex case types with lots of optional actions, flows, alternate stages and custom DX portal widgets.

1 Like