See more similar articles in Constellation 101 series.
Thank you Piotr Kupczyk and Dawid Stefanik for coauthoring this article.
Why
Article presents how you can implement complex data visualization requirement using Pega Constellation out-of-the box functionality. It is often assumed that to create rich and complex screens we need to employ Extension DX Components. This article provides information on how to design and implement complex UI requirements using what out-of-the box in Pega Constellation UI.
Additionally a frequent ask from community is they would like to see more detailed implementation guidance. This is a reasonable ask as the tools that you need to use in Constellation (to be successful) are different to what you might have used to in Traditional UI. This article aims to provide such guidance. By leveraging Embedded and Reference Data fields along with diverse types of Views, you can effectively manage hierarchies, enabling intuitive data visualization and navigation between data entities.
Overview
To my surprise, I’ve noticed a strange misconception among Pega Architects - both beginners and seasoned professionals - when they first encounter Constellation. Many seem to believe that it’s not suited to handle more “sophisticated” UI requirements beyond simple forms where users merely input their basic data or attach a file. Of course, I fully understand the concerns and uncertainties that often arise with new technologies. However, let’s not focus on the “why” right now. Instead, let’s challenge this assumption by tackling a complex use case with a more advanced UI requirements – one that is commonly believed to be impossible to implement in Constellation and … try to implement it in Constellation!
For purpose of this article, we will focus on an Onboarding Case centered around reviewing application documents. In this scenario, documents are organized into Catalogs, which are further grouped into Dossiers. This is hierarchy of objects that we want to present to the user:
Before diving deep into implementation details let’s see what business requirement we try to solve here and what are the benefits of presented solution
Business use cases
- Organize documents into nested structures (e.g., Dossiers, Catalogs, and Documents).
- Present complex information in a transparent, user-friendly layout.
- Allow seamless navigation, editing, and opening of data entities in a new browser window.
Benefits
- Improving the user experience by providing intuitive visualization of complex data and seamless navigation between data entities.
Implementation approach
Let’s start planning the implementation of our requirement. The step View needs to display a hierarchical list: Dossiers containing multiple Catalogs, and each Catalog holding multiple Documents. Additionally, the user should be able to open each document and edit it if needed. In simpler terms, this is a nested document tree. In a traditional UI, you’d probably implement this using a dynamic repeating layout with several nested sections, extensive configurations in the Full Section Editor, and carefully set up action sets. A lot of things to do in Dev Studio, right?
But how can we achieve this in Constellation? Let’s find out! And let’s try it in two different ways:
- With a modern, a little more user-friendly approach using repeating views.
- With a more classical approach using tables with grouping options.
To give you a big picture and clarity of what we are building, here is the end result:
- Nested structure of repeating layouts as first solution
- As an alternative approach, table with grouping configuration enabled.
Implementation overview
A step-by-step guide for implementing the presented use case is provided in the attached document, which is available at the end of the article. The article itself provides a high-level overview of the implementation steps. Also reference application, along with the base application with defined data objects and Case Type, can be found in attachments to allow you better follow the article.
Data model
In our scenario, three Data Objects - Document, Catalog, and Dossier - form the foundation of our structured hierarchy. Let’s take a closer look at each of them.
At the top level, we have the Onboarding Case Type. This is the starting point – the container for all the data that we gather and modify. Each case holds a collection of Dossiers, acting as the primary organizational unit. Inside each Dossier, we will find a collection of Catalogs. Theses Catalogs serve as subcategories, breaking down the content further for better organization.
Finally, withing each Catalog, there are individual Documents. These are the smallest pieces of data, such as PDFs, forms, XML files along with metadata. Documents sit at the bottom of the hierarchy, and they are the content being managed and revised.
We model those entities as nested structure of Embedded Data under Onboarding case. Common misconception is that Embedded Data field type is suitable only in case of manual entry of data by the user. This is one of the use cases, but we can fill data on Embedded Data by Data Transforms. This is what we do in our scenario. Structure of Dossiers and Catalagos is predefined by business logic and Document could be fetched from external SOR via REST.
The primary drives to use Embedded Data are:
-
the need to use Repeating Layout which is only available for Embedded Data field type
-
our data is saved on case not immediately synchronized with external SOR, so user can play with data and we can have an approval step afterwards
Once your data model is well-defined, Constellation is good at supporting your requirements with producing end UI tailored to your needs as UI is tightly coupled with data model. In Constellation to present anything on screen you need to have corresponding data model.
Let’s see how you can enable Preview functionality for our data entities - Dossier, Catalog, and Document. You want to give users the ability to click on a field, and with one action, either preview the content or open the full entity in a separate browser window. To achieve this, we need to add additional Data Reference field for each object. Here’s how it looks for the user:
For Dossier, Catalog, and Document, we add Reference Data fields (for example: Dossier Reference, Catalog Reference, and Document Reference) to provide clickable links for previewing or opening each item. This is the additional data model configuration that you need to perform to enable this feature, it is not a consequence of modelling relation between entities for data modelling perspective.
This approach is common when building Constellation application. Your data model is the Enterprise Data Model (the business entities and relations between them) as well as “working” data model on a Case that supports the UI that you want to build.
User Interface
Now, let’s look at the UI implementation. This document showcases two approaches to achieve the same business outcome:
- Configuration using Repeating Views (picture 2 in this article) – imagine presenting the document structure as an expandable tree. To achieve this, we’ll use the Repeating View option on the Embedded Data field. It’s a clean and intuitive way to represent nested data, ensuring users can easily navigate through Dossiers, Catalogs, and Documents.
- Configuration using single List View (picture 3 in this article) – alternatively, we can represent the same expandable tree structure using a List View. By applying the appropriate grouping options, this method simplifies the configuration while maintaining functionality. Whether implemented in a flow action or a landing page, this approach also ensures updates to the System of Record – even if the data is sourced externally.
Note: please refer to the attached document to see detailed instructions for configuration steps
Solution 1: Configuration using Repeating Views
Start views configuration from the bottom (Document and Catalog level) and climb up reusing views created on layers below.
Step 1 – Configure View for Catalog
The Catalog View focuses on managing Catalog-level data. Each Catalog includes an editable table where users can view, add, or update associated Documents and read Catalog details. This setup is powered by the Documents Embedded Data (List mode) defined on the Catalog Data Object. When Documents fields is added to a view we configure its display as Table. View type is set to Form to allow edit of Documents.
Step 2 – Configure top level Dossier View
The Dossier View serves as the top container of the hierarchy. It includes fields for basic information and expandable field groups for associated Catalogs. These field groups are powered by a Catalogs Embedded Data (List mode) , configured with Repeating Views within the Dossier Data Object. This enables dynamic display of nested Catalogs as users interact with the Dossier. We enabled Field Groups feature to group related properties on a screen in a visual way. View type is set to Form to allow edit of Documents below in nested structure,
Step 3 – Enable CRUD operations on Document
To improve the user experience during CRUD operations, we use a modal-based approach. Users can add, edit, or preview Documents seamlessly via modals. This requires proper configuration of the Documents Embedded Data within Catalog View.
Note: implementation of syncing data with external SOR is not covered by this article
Step 4 – Integrating into the Onboarding Process
Once the views are configured, they need to be integrated into the Onboarding process. This can be achieved by leveraging the Dossiers Embedded Data with a Repeating Views configuration, along with the top-level view defined for the Dossier.
Since embedded data is being used, it’s important to ensure that existing Documents, Catalogs, or Dossiers are properly populated. This is done through pre-processing Data Transforms and a pre-configured Data Pages.
Step 5 – Enabling preview functionality
Finally, we enable the Preview feature. Each view includes a clickable link to quickly view entity details in a separate tab for Dossier, Catalog and Document objects. These links are configured using Reference Data fields, which need to be created and added to the respective views.
Step 6 – Supporting CRUD operations
We ensure flexibility by supporting CRUD operations directly within the interface. Users can manage Documents through modal-based interactions, enabled by properly configuring the Documents Embedded Data in the Catalog View and defining the appropriate views within the Document data object.
Note: implementation of syncing data with external SOR is not covered by this article
By following these steps, we provide a user-friendly framework for managing complex hierarchical data structures in Pega. This approach leverages features like Embedded Data, Repeating Views, and dynamic Data Pages to create an intuitive and efficient user experience.
Solution 2: Configuration using single List View
Step 1 – Setting up the report and data page
The foundation of this configuration begins with a custom report that retrieves a list of documents. To achieve this, the report must include information indicating which Catalog and Dossier each Document belongs to. That data is essential and must be returned by the report, because it will be used for grouping purposes.
Step 2 – Creating a view
To display the hierarchy, a new form view is created within the relevant flow action. A new List View, configured as a table, is embedded into this form, serving as the primary interface for users to interact with the data.
Step 3 – Set up the List View
The List View uses a previously created data page as its source and includes key fields such as Document Number, Catalog Name, and Dossier Name. Hierarchical grouping is configured using fields like Dossier Name and Catalog Name, allowing the data to be displayed as a structured, expandable tree. CRUD operations are enabled directly within List View, giving users the ability to add, edit, or delete records in real-time. Embedded within the form, List View serves as the primary interface for user interaction with the data.
Step 4 – Configure links
One of the fields is configured as a clickable link using View Designer. Clicking this link enables users to view additional details about the document or navigate directly to the object. This adds an intuitive and interactive element to the interface.
CRUD operations side note
Any changes made within List View - such as adding, editing, or deleting records - are instantly reflected in the System of Record. If the data page is connected to an external System of Record, these changes are synchronized automatically, ensuring real-time data accuracy.
Note: implementation of syncing data with external SOR is not covered by this article
This method offers a more “classical” approach to data visualization while retaining modern functionalities like CRUD operations and dynamic grouping. It is well-suited for use cases requiring direct interaction with Systems of Record.
Conclusions
We’ve seen how Constellation can handle even the most complex UI challenges. What might seem like a difficult task - managing nested data structures - becomes simple and efficient with the right tools. Using Repeating Views and List Views, we’ve shown two clear ways to create dynamic and easy-to-use interfaces.
Constellation isn’t just capable - it’s flexible. It proves that even advanced requirements can be solved in a straightforward and user-friendly way, giving us the confidence to tackle any challenge.
Constellation 101 Series
Enjoyed this article? See more similar articles in Constellation 101 series.
CDV_Base_09_01_2025.zip (1.46 MB)
CDV_Reference_09_01_2025.zip (1.95 MB)
Complex Data Visualization - Detail Implementation.pdf (4.47 MB)
