Nested Expandable Table Custom DX component

User Experience
,
1

Hi Team,

We are working on Pega Constellation 25.1.3 and have a requirement to display a parent-child hierarchy using data stored in a single Data Object/Data Table.

The table contains both parent and child records, with a Parent ID column used to establish the relationship between them.

Our goal is to display this hierarchy on a Landing Page (Dashboard under UI page class) in a way that allows users to easily understand the parent-child relationships.

Challenges Encountered

  1. Since the source is a Data Object and the UI is a Landing Page, we cannot leverage Embedded Data views/components as we would in a case context.

  2. The Landing Page only provides the option to configure a List View table.

  3. We explored using the Pega-provided custom DX Nested Expandable Table component to render the parent-child hierarchy. However, it appears that custom DX components are either not supported or cannot be configured as expected within Landing Pages for UI pages class , preventing us from leveraging this approach.

  4. As a result, we have not found a native way to present expandable parent-child data similar to a tree grid.

  5. storybook - Storybook

Question

What is the recommended or best-practice approach in Constellation 25.1.3 for displaying hierarchical parent-child data from a Data Object on a Landing Page? We are facing issues mainly due to restrictions of UI-page class .

2

I hope you can use Group by Parent Case ID in your Insights to build the hierarchy

3

Thank you for your reply @RameshSangili . Apart from Insights is there any better option to represent it on UI as the portal is for end users.

4

For a read-only Landing Page, the recommended approach is to retain the data in a flat structure and use a List View or Insight with one or more grouping levels based on ParentID, parent name, and child type. List Views and Insights support multiple grouping levels and provide useful filtering, sorting, and personalisation capabilities.

If grouping is not sufficient, create a reporting data page/data view that returns a display-ready hierarchy with fields such as Level, ParentName, DisplayName, HasChildren, and SortPath. The List View can then display an indented/ordered hierarchy without requiring a custom tree control.

If a true expandable tree with lazy loading is mandatory, use a custom Constellation DX component. Confirm that the component supports the UI Page/Landing Page class and can consume the required data page or data-view endpoint. Constellation DX Components are intended for extending the standard component library, and a custom widget can be used to retrieve data from a data page and render it on a Landing Page.

So, my choice is:

  • Use grouped List View/Insight if analysis and filtering are sufficient or
  • Use a flattened, display-ready hierarchy source if indentation is required or
  • Use a custom DX widget/component only when genuine expand/collapse behaviour is a hard requirement

I would not use the Case Hierarchy widget or manually inject unsupported components into the UI Page view JSON for this non-case Data Object scenario.

5

@RaviChandra :

Thank you for the suggestions.

One additional requirement in our use case is that both Parent and Child records must be individually clickable and open their respective Data Object details (both records originate from the same underlying table).

My concern with grouping by Parent Name is that the parent record becomes a group header rather than a selectable row, which appears to remove the ability to navigate directly to the Parent Data Object details.

In this scenario, what would be the recommended Constellation pattern for maintaining a hierarchical view while also preserving navigation links for both Parent and Child records?

Currently, we are displaying a list of Parent records as clickable links. When a user selects a Parent record, we navigate to its Data Object details page and display a separate table containing the corresponding Child records. While this approach works, it requires multiple clicks and makes it harder for users to understand the hierarchy at a glance.

We are therefore exploring whether there is a more user-friendly and supported approach in Constellation 25.1.3 that can provide:

  • A hierarchical parent-child view
  • Clickable navigation for both Parent and Child records
  • Minimal user clicks
  • Support within a Landing Page/Data Object context

Has anyone implemented a similar pattern or found a recommended Constellation approach for this requirement?

6

Yes, in a grouped List View, the parent value is rendered as a group header, not as a normal data row. That means it does not naturally provide the same navigation behaviour as a selectable Parent record. So it would be better if you can look at this as 2 requirement concerns one to “represent the hierarchy” and other to “navigate to each record”. So, for this requirement, I would recommend returning a flattened hierarchy in which both Parent and Child records are represented as individual rows.
The data view should include fields like- RecordID, ParentID, RecordName, RecordLevel, RecordType, HasChildren, and SortPath.
Sort by SortPath so that each parent is followed by its children.

The RecordName column can then be configured as a link to the corresponding Data Object details view where supported. If direct object-link configuration is unavailable for the Data Object-backed List View, add a row-level View details action that receives the current row’s RecordID and opens the appropriate Data Object view.

This gives you a single view with:

  • Parent records and Child records displayed as real selectable rows providing independent navigation for both record types
  • No need to navigate to a parent page before seeing the children
  • A pattern that remains within the standard Landing Page/List View model

If true expand/collapse behaviour is mandatory, use a custom Constellation DX component backed by a parameterized, queryable data view. The component should load root records first and retrieve children using ParentID when a parent is expanded. Confirm that the component supports the UI Page/Landing Page class before adopting it.

So I would recommend the flattened hierarchy + links/row actions as the first option. It satisfies the navigation requirement with the least customisation. Move to a custom expandable component only if users specifically require interactive expand/collapse rather than an always-visible hierarchical list.

7

Thank you @RaviChandra for your suggestion.

Could you please confirm whether the Nested Expandable Table component (referenced in the link provided in my original post) can be used for this use case?

I attempted to use it within a UI Page (Landing Page) context, but Pega does not appear to allow the corresponding view to be configured on the UI-Page class. Based on my testing, it seems that the component is intended to work only with Embedded Data and not directly with Data Objects exposed through a Landing Page.

Is my understanding correct, or is there a supported way to use the Nested Expandable Table component with Data Objects in a Landing Page/UI Page context?

8

@Mayurk33

Based on the behaviour you described earlier, your understanding is correct. However, the Nested Expandable Table in the Constellation UI Gallery should not be assumed to be an OOTB generic tree-grid for arbitrary Data Object records on a UI Page/Landing Page. It is a template/custom DX component pattern whose supported configuration depends on the data structure and page context for which the component was built.

The Nested Expandable Table component cannot be used as-is for this requirement through the standard UI Page/Landing Page configuration. It is not a generic tree-grid for flat Data Object records, and the fact that it appears in the Constellation UI Gallery does not mean that it is supported for every page class or data source.

A Landing Page/UI Page is list-oriented and does not provide the same embedded-data context as a case view. If Pega does not allow the component’s view to be configured on the UI-Page class, then there is no standard configuration switch that makes it available for that context. Landing Pages are primarily designed for list-based pages, including Data Object tables with filtering, sorting, and CRUD configuration.

So your requirement is only possible through a customised DX component implementation, not by directly binding the Gallery component in the standard Landing Page designer.

If expand/collapse is mandatory, the extension route is to create an app-specific DX component based on the expandable-table pattern. That component must consume a queryable data view, resolve children by ParentID, and implement the required parent/child navigation.

If custom development is not desired, then use a standard Landing Page List View backed by a flattened hierarchy data view. Return both parent and child records as rows, add a SortPath/Level for hierarchy display, and configure the record name or row action to open the corresponding Data Object details. This will preserve navigation for both record types, however it will not provide true expand/collapse behaviour.

So, the Gallery component can be used as a reference or starting point for a custom implementation, but it is not directly supported as a configurable Nested Expandable Table for arbitrary Data Objects on a UI Page in the scenario described. The fact that Pega prevents the view from being configured on the UI-Page class is an indication of that page-context limitation, not a missing setting.