Why:

During one of our projects, we identified the need to implement an advanced search capability that addressed a comprehensive set of requirements.

Given that the project leverages the Blending architecture — which enables both UIKit/Themes Cosmos and Constellation case types to function within the same portal — it was essential to ensure that case workers could efficiently search and retrieve cases across both architectures. While UIKit already provided a search feature, its functionality was limited to legacy case types. To deliver a unified and streamlined user experience, our objective was to design and implement a single, consistent search solution capable of supporting both UIKit and Constellation case types.

Advanced search use case:

Case workers require a robust, secure, and user-friendly search capability within the Pega Constellation platform to efficiently locate cases and related information. Our objective was to design and implement a comprehensive search solution within Constellation.

Key Requirements:

Search Filters

• Support cross–case-type queries using key identifiers and parameters, enabling comprehensive searches across different business applications.
• Certain filters are mandatory to initiate a search, while others are optional and can be applied to refine results further.

Default Load

• The search results should remain empty on the initial load.
• Results must only be displayed following a user-initiated action (e.g., entering a search parameter).

Integration-Based Access Control (ABAC)

• Enforce attribute-based access control through external integrations to validate case worker permissions.
• For example, when a customer number is used as a filter, the system verifies whether the case worker has permission to access that customer’s data. Results are rendered only if access is granted.

External Data Integrations

• Leverage external integrations during the search process to retrieve additional case-related data.
• Some filters must invoke APIs to populate dropdown values dynamically.

Audit Logging and Compliance

• Ensure all search operations comply with organizational cybersecurity and privacy standards.
• Log all search activities in an external, audit-compliant logging system for traceability and compliance.

Error Handling

• Provide clear and user-friendly error messages for scenarios such as missing mandatory filters, invalid inputs, insufficient access rights, or integration failures.
• Ensure guidance is actionable and supports quick resolution.

Search Results

• Present search results in a structured, easy-to-read list or tabular format to enhance usability and efficiency.

Actions on Search Result Items

• Case workers can access a case by selecting the designated column value, which is presented as a hyperlink.
• When user personalization is enabled, case workers are able to configure custom views by showing or hiding columns, grouping data, and applying additional filters within the results table.

Accessibility Compliance

• Ensure that the search functionality complies with accessibility standards WCAG 2.1.

Solutioning:

Initial investigations showed that there are following technical solutions:

• List views
• Insights
• Mashup with UIKit
• Extension DX components

Rationale for Choosing the Solution:

• Mashup - The UIKit search functionality is limited to searching within UIKit case types. Implementing it as a mashup would not fully meet our requirements. Additionally, rendering a UIKit landing page as a mashup within the Constellation portal does not always provide an optimal user experience and can sometimes result in performance issues such as slowness. For these reasons, we decided against pursuing the mashup approach.
• Extension DX Component -Developing a new DX component would require specialized React expertise. Managing the lifecycle of such a component is complex, as it demands additional resources, increased effort, and alignment with React version upgrades. Consequently, we chose not to design a new DX component for this purpose.

Taking these considerations into account, we opted for an Out-of-the-Box (OOTB) Constellation approach, leveraging either List Views or Insights. Below is a comparison between the two options, along with the rationale for our final selection.

List Views vs Insights comparison (24.2.2) - to decide whether we should use List Views or Insight we run detailed analysis to compare both solutions:

Why we chose List View over Insights:

Based on the comparison, we found several advantages of using List View instead of Insights:

• Flexible data sourcing: List Views offer greater flexibility for handling complex data sourcing. Insights, on the other hand, require additional considerations that don’t align well with our current advanced search use cases.
• Custom hyperlink support: Insights do not allow adding hyperlinks to custom columns, whereas List Views do. Since our requirement was to avoid using Pega’s OOTB field as the hyperlink for opening cases, this became a key reason to select List View.
• Better localization support: Localization is much simpler and more effective in List Views, while Insights still come with certain limitations.
• Runtime formatting options: For scenarios where column values need to be formatted dynamically during UI rendering (e.g., formatting SSN as yyyyMMdd-xxxx), List Views make this possible through custom DX components with VIEW-JSON customization. This is not feasible in Insights.

List View and Insights – beyond Pega 24:

Following the above comparison, we have opted for the list view design, as it currently offers superior flexibility and advantages. At the same time, Pega continues to enhance the capabilities of Insights, with the objective of incorporating the full range of functionalities presently available in list views. While Pega recommends leveraging insights for such use cases, our requirements are highly advanced and necessitate the flexibility provided by list views at this stage. Accordingly, we will proceed with list views for the present, with the intent to migrate to Insights in the future once Pega introduces more advanced features and greater flexibility.

Implementation:

Basic configuration of landing page and list view

​Why we chose Connect-Rest as the source

We selected Connect-Rest as the source for the list data page to support the requirements of advanced search.

• Our key need was to display an empty list on the initial load while still performing aggregation across multiple tables. Standard aggregation sources do not provide this level of flexibility. Connect-Rest, however, allowed us to achieve both an empty initial load and aggregation within its code set.
• It also provides greater flexibility by letting us encapsulate pre- and post-processing logic inside its code components (Request & Response DT). For our advanced use case, we required several validations and access checks based on user-supplied search parameters, along with post-search security logging. This design makes all of these requirements feasible.
• Additionally, Connect-Rest can source data from external systems and aggregate results from multiple sets. This makes the results query-able, enabling infinite scrolling and simplifying pagination within the design.

Technical design, empty list on load, and fetch the search results

Please refer to the article for detailed design: How to configure the Connect-Rest and how to configure the Service-Rest to fetch the search results.

Empty List on Load in Constellation Landing page

Access control and error handling

Ref. previous article link

Audit logging

Ref. previous article link

Hyperlink on custom column

When configuring list views, Pega by default assigns certain out-of-the-box (OOTB) fields (e.g., Label, Case ID) as hyperlinks to open the work object. These default hyperlinks can be removed, and instead, custom project-specific fields may be designated as hyperlinks to open the case.