Suggestions for Enhancing Flexibility in Pega Constellation (Based on Hands-on Experience)

User Experience
,
1

Hello everyone,

Hope things are going well at your end.

Over the past several months of working extensively with Pega Constellation, I’ve had the opportunity to explore many of its out-of-the-box capabilities across different use cases. The platform has evolved significantly, especially in terms of standardization and developer productivity.

That said, after practical usage and implementation across scenarios, I wanted to share a few observations and suggestions that could further enhance flexibility and help teams build more robust solutions.

Here are top 10 of them. Please rate them on the scale of (1-10) based on your opinion of whether they are surely needed (10) or not needed (1). Let’s make it interactive.

1. Enhancing Dynamic Text Capabilities

Currently, Dynamic Text supports only plain text. It would be highly beneficial if support for rich text formatting could be introduced.
Additionally, enabling the ability to invoke functions or reference other rules dynamically would significantly improve reusability and allow more contextual rendering of information. Switching modes between static and dynamic text would be of great help.

2. Conditional Column Visibility in Tables

List views, data reference tables, and galleries currently do not support conditional show/hide of columns.
Providing this capability would give developers better control to tailor UI behavior based on business logic, instead of relying solely on end-user personalization.

3. Inline Editing Consistency for Multi-Select Fields

When using multi-select fields (sourced from another data object) within embedded tables, these are currently available only via modal or repeating views.
They are not accessible in inline row editing mode, which creates an inconsistency in user experience. Enabling support for inline usage would make the behavior more uniform and intuitive.

4. Conditional Control for Stakeholder Addition

In the Utilities > Stakeholders widget, there is currently no option to conditionally control the visibility of the “+” (Add) action.
Introducing a “when condition” capability here would allow better governance based on case state or user roles.

5. Customization of Assignments Widget Content

The Assignments widget is very useful, but currently offers limited flexibility in customizing displayed information such as flow action names, urgency, or contextual metadata.
Providing extension points (e.g., views, when rules) would enable developers to tailor the display based on specific requirements.

6. Flexible Case Summary Layout (Top vs Left Panel)

In the case view, fields configured in the summary block are reused in both the top header (collapsed view) and left panel (expanded view).
It would be helpful to have separate configuration options for these two areas:

  • Top header → frequently accessed information
  • Left panel → supplementary or less frequently used details

This would improve information hierarchy and usability.
(Also, the current tabs/accordion behavior works well—no concerns there.)

7. Conditional Collapsing of UI Sections

Providing the ability to conditionally collapse or expand:

  • Field groups
  • Embedded views
  • Repeating views (embedded lists)

would improve UI responsiveness and relevance.
I understand there has already been some discussion on this topic by @MarcCheong , and it would be great to see this evolve further.

8. Manual Refresh and Close Actions for Cases

Having a manual “Refresh” and “Close” capability for cases—similar to the existing “Follow” action—would be a useful addition.
With appropriate extension points (e.g., when conditions), this could provide better control for specific scenarios.

9. Localization Improvements

While the introduction of bundle-based localization (from v25 onwards) is a positive step and simplifies maintenance, there are still some known issues—particularly in Insights (as observed in version 25.1.2).
Addressing these would greatly improve global usability.

10. Enhanced Visual Feedback for Fields

Currently, “Show field warning” provides a good way to highlight warnings.
Extending this concept to include:

  • Success indicators

  • Error indicators (with icons and color cues)

would provide clearer visual feedback for both manual inputs and automated data mapping outcomes.

Closing Thoughts

These suggestions are shared with the intent of contributing to the ongoing evolution of Constellation. The platform already provides a strong foundation, and incremental enhancements like these could further empower developers while maintaining its design principles.

Would be great to hear thoughts from others in the community and see if similar needs have come up in different implementations.

Also if you have any more items in your mind, please drop them in the replies and it will be easy for everyone to view them and provide their feedback.

Happy coding and exploration!!! :slight_smile:

Regards

JC

2

Great thoughts!
I can say for our clients, items 4, 5, 6 & 8 in your list are absolute must haves (rated 10 on your scale).

I can’t understand why we as developers do not have the ability to change the display name of some of these widgets. I found a way around the name “Pulse” but I have not yet found a way to change the display name of “Stakeholders” for the Stakeholders widget. What if we have a subset of work parties/participants that the client wants to name “Stakeholders”? That’s a confusing user experience to have it display as Stakeholders when it contains Participants called Stakeholders, also Customers, also Owners, etc. and when adding one the modal always says “Add stakeholder” even though we may be adding an Owner. Please don’t hard code those values or at least give us a mechanism to change that display name.

The same goes for hiding/showing/visibility condition. That, along with custom actions, was one of the best/most flexible parts of Cosmos and we lost much of that ability with Constellation.

Our number one item of feedback from clients is always about the UI. “Can you change the name of X to Y”, etc. Pega’s lexicon/industry vocabulary is not always the same that every other client wants to use in their business.

1 Like
3

Many thanks @JonathanB9941 for your feedback. Appreciate your time taken to read through the items and provide your rating.

For changing the display name of the widgets and any other labels on the UI, i guess we can utilize the localization rules where you can change the label name both for base language and also for the localized language as well. You can look at the Individual view scoped localization rules until v24 and bundle localization rule in v25 which you can modify using the overriding mechanism from application rule.

Regards

JC

4

Thanks for the post and feedback, Jayachandra Siddipeta.
Most of the topics/issues you highlighted are addressed / coming in our latest release *26.1.

2 Likes
5

@Sreedhar_Ganduri Many thanks for the reply and glad to know that these feedbacks are being taken care already. Hope with these new enhancements developers and business users will have more leverage to work on constellation.

Regards

JC

6

@JayachandraSiddipeta thank you for the suggestion on changing the widget display. Will this work on a Pega OOTB widget such as the “Stakeholders” widget? I’m looking to not only change the title “Stakeholders” but also on the subsequent modal that says “Add stakeholder” when user clicks the plus “+” icon within the widget. I tried a couple of localization and Field Value changes, but none seemed to affect the OOTB widget as I assume that view code is very locked down.
Maybe I configured things incorrectly. Can you provide more detail on your idea/solution to update the display values of views internal to Pega OOTB widgets?

8

Great insights, JC! From our hands-on experience, items 1, 2, 4, 6, and 8 are absolute must-haves for our client.

  • 1 – Rich text and function support in Dynamic Text is critical for reusability.

  • 2 – Conditional column visibility is a frequent enterprise ask for role/state-based UI control.

  • 4 – A “when condition” on Stakeholder Add is essential for proper case governance.

  • 6 – Separate configuration for the top header and left panel would significantly improve information hierarchy.

  • 8 – Native Refresh and Close actions with when conditions would reduce many workarounds in operational workflows. Rating all five a solid 9/10. Hope to see these on the roadmap soon!

2 Likes
9

Hello @JonathanB9941

In v25, with overrides scoped localization rule, you can update the base bundle as shown below and you should be able to update the labels for all the utilities related content easily.

image
image904×710 105 KB

image
image760×416 18.8 KB

And once you do the above, you output should look something like below,

image
image904×552 41.6 KB

With this approach, even if you localize your application to any other language, you would still have the content as per the language chosen without hardcoding anything.

image
image2446×1430 167 KB

For v24, you might have to so an all content + exact match search for the strings like “add_stakeholders“ or “view_stakeholders“ and you should find the base localization rules. Mostly it would be pyGenericFields or pzPlatformFields,etc. Most probably you should be able to modify them as they would be available rules only.

I have tried to modify the pyGenericFields rule in v24 and it did not work for me. The key in the localization rule was “CosmosFields“. When i updated it to “COSMOSFIELDS“ in v25 it did work. But did the same approach in v24 it did not work. May be something got fixed in v25 i believe.

Hope this helps

Regards

JC

2 Likes
10

@JayachandraSiddipeta , many of those things you listed were already flagged a long time ago. Specially the stakeholder widget, localization could be achieved easily if you know where to look. The main thing is that you want to limit who can add/remove stakeholders (point 4) as this may lead to routing errors. In many cases I have created a custom widget which achieves just that (and that is the beauty of Constellation).

The column visibility (2) can already be achieved, you just need to create a list type, and than have multiple ‘views’ to it.

1 thing I don’t get is your point 8: Manual Refresh and Close Actions for Cases

Constellation act as a SPA, so you can just hit the refresh button on your browser (but if you need to, perhaps there is a need for a different design?). Even the close; What do you expect, return to the previous page - use the back button. Go ‘home’, click the home button (saves you 1 click).

1 Like
11

Many thanks @RonaldDeLignie for your feedback. Sreedhar already mentioned the fact that most of these items are already flagged for enhancement in future versions.

# Point 4: Replacing the labels of Stakeholders widget can be done with localization as i mentioned in my previous reply. A general expectation from developers would be to have at least an extension point where a customization can be performed in the modules where key workflow elements reside. I would always keep custom component as the last resort, unless and until we don’t have an OOTB alternative and the functionality is business critical.

# Point 2: For column visibility of tables, had there been an option of setting up when rule for each column in a single view, why should a developer need to add multiple views with different conditions. This would lead to maintenance overhead and redundancy of the common columns displayed in multiple tables.

# Point 8 : Yes i do agree to your point. This item was added based on the posts i have seen and questions asked by other developers and colleagues. I would personally treat this as a lowest priority as we do have alternatives.

Regards

JC

1 Like
12

The label of the widget can also be replaced inside the view config, but translation will do a similar job.

Personally don’t agree with point 2. The point I think we should be discussing, is what does the user want to achieve with multiple views on the same table. Than we can discuss how to build this.

In constellation the option chosen is to allow multiple views on the same list-table (in 1 configuration area). For me this is even easier than having when conditions, as now it is 100% clear for what which view is meant for. Benefit; it has a descriptive label as well :slight_smile: .

What I rather prefer that tables can do is to allow configuration of aggregations (now can only be done in runtime)

13

@Sreedhar_Ganduri ; I submitted that request a long time back, any chance that it will come into the 26.1 release

14

@RonaldDeLignie Yes, agreed that its purely based on what users really need.

Personalization of table for users is a very good option for users to have their own choice of views at run time rather than you set it up during design time. This will avoid dependency on the developer and save time for change release.

Having said that, there may be scenarios where we don’t need personalization but have conditions on the columns so that you don’t need to display depending upon the data.

From the forums, there are few points mentioned about personalization in other posts like,

  1. If a change happens in a release, then users have to intimated about the change as the changes made on the base list view will not be propagated to personalized views. It might show stale columns, filters, sort setup, etc. The same topic has been mentioned in this post Making Tables Work Harder: A Practitioner’s Guide to Sorting, Filtering, Grouping & Personalization in Constellation
  2. Few limitations on the behaviour of the refresh strategies when you custom views on the table. When switching user saved views DB is getting hit without considering loading mechanism

For now its just 2 posts i noticed and hence this point made its way to the list.

Regards

JC

1 Like
15

@JayachandraSiddipeta , adding 1 more to your list.

@Sreedhar_Ganduri -

Although we can use pxAddMessage in the Embedded Data modal dialog when the user clicks Submit, the modal dialog does not refresh dynamically based on conditions.

For example, when a user enters address information, we need to call an API to validate the address. If the API returns a suggested address, that updated information is not automatically refreshed on the UI within the modal dialog. In such cases, we need to present the user with options such as Select Entered Address or Suggested Address.

We have currently achieved this using a different approach without adding pxAddMessage on Submit, but this is still an important consideration for future improvement.

1 Like
16

@JayachandraSiddipeta a fantastic write up and delve into real life feedback. A big thanks for taking the time to detailing this - its invaluable insights!

1 Like
17

Thanks JC! I have been able to follow these steps for Pega 25 and it works like a charm. I can’t figure out 24 yet, like you mention, but will keep trying. Thank you again.

1 Like