Search and Select pattern in Constellation provides convenient and consistent user interface to perform complex searches on large data sets using data reference field. For example - As a customer service agent, I need to quickly find a customer’s profile in a database using partial details like name, email, or phone number. 

Detailed implementation steps for this pattern are available at Configuring Search and Select.

In some situations, it may be necessary to tweak this pattern to accommodate specific user requirements. Some of these are discussed below. 

Note: These should be implemented only when there is a trade-off between developing a custom component and extending the out-of-the-box (OOTB) pattern. Otherwise, it is preferable to use the default functionality provided. 

Here are four uses cases that we are going to cover- 

1. Using OOTB search and select pattern when the data is fetched from an external data source. 

2. Using OOTB search and select pattern to search the data using date range. 

3. Using OOTB search and select pattern to configure advanced search. 

4. Using OOTB search and select pattern to show all the selected items below the search screen. 

Advanced Use Cases for Search and Select Pattern

Use Case 1: Search and Select from an external Data Source 

To configure search and select functionality on data sourced from a REST API, additional configuration is required to ensure that the search and select pattern operates similarly to how it functions with local storage. 

We need to set up: 

• A Data object with source as API. 

• Custom keys for the Data object. 

• A new wrapper Data Page, which internally is sourced from the main Data Page. 

• Parameter Page to pass the search fields to the API. 

• Search View using a data reference field. 

Detailed implementation steps for this pattern are available at Search and Select from an external source.

 

Use Case 2: Search based on Date Range 

Currently, data range search is not supported by default. But it is possible to implement date range filtering by applying the same method used for external data sources. 

Example Use Case: The system should provide functionality to retrieve credit card statements by entering a specific date range. 

 

Solution: 

1. Create data object to store the credit card statements. For this example, I am using local storage. In actual implementation it may be a REST API. 

      2. Create a new List Data Page and the corresponding Report Definition to use data range as filter.

Note: Do not alter the DataTableEditorReport in any scenario, as it helps load the data designer view. If you need any variation, create your own report definition.

      3. Create another wrapper Data Page and enable “Allow query using a JSON object “checkbox. This Data Page should have no parameters.

 

      4. Configure the source as a Data Transform and pass the parameters using pySearchPageName Page parameter.

 

Note: You may have to tweak the date format before passing those as parameters to the main data page to align with your data structure.

      5. Create a Data reference field and configure your search screen by adding 2 date field – Start Date and End Date. Use the wrapper Data Page as a source from your view.

 

Once you complete the setup you will be able to search for the results easily with a date range.

 

Note: These filters cannot be set as mandatory because they do not operate directly on the main Data Page.

 

Use Case 3: Using Advanced search check box

The same methodology can be applied to construct an advanced search group, which may be passed as the parameter to the Data Page as necessary. The resulting search view will resemble the following –

 

 

Use Case 4: Show all selected items

Users may apply multiple search criteria to filter data and select several records using out-of-the-box search and selection features. A separate table is needed below to display the selected items.

Challenge:

The current search and select pattern display results based only on the current search criteria. Items selected earlier are not displayed when the search criteria are changed.

Proposed Solution:

1. Create a screen flow

• The search and select view can be maintained on screen 1, after which the same data reference field may be used to display a table on the subsequent screen.
• This approach is efficient and requires minimal development effort. It’s recommended for several reasons:
• Multiple screens minimize vertical scrolling, particularly when there are more than ten selections or when viewed on smaller devices.
• It reduces development time, as the platform will automatically map the data to the case; once you enable “Reference Data is copied to the case” checkbox.
• Requiring one additional click is not a significant drawback, given other constraints related to the available screen space that must be considered.

 

Continuing the previous example, we can use the same Data Reference field and create a screen flow as shown below:

 

 

Post your configurations, this is how the screen will look like.

 

 

         2.Adding a declare expression

If it is necessary to display both tables simultaneously, a declare expression should be added to ensure the table refreshes according to your selection.

Both the tables will be shown on the same screen and there is no need for a screen flow.

 

Steps to configure –

1.Create a new field on the case data model. Configure a declare expression on the same to be LengthOfPageList(<Data Reference_fieldname>).

2.Add this field to your search view with a custom visibility condition that results in false. Do not use a when rule because we need to run this on client side for the screen to refresh.

3.Now in your view add the data reference field twice. Once as Advanced Search and one as read only. CardStatements field is already configured to copy data on case.

 

This approach will allow you to show the selected records dynamically refreshed on any mutation in the Advanced Search in the same view.

Summary

In summary, the OOTB search and select patterns can be adapted for advanced use cases without requiring custom components. This flexibility allows developers to maintain consistency while addressing varying application requirements.

Additional References

You can read more about the OOTB Search and Select pattern in these articles:

• https://community.pega.com/conversations/user-experience/search-select-and-review-pattern

• Configuring Search and Select

• https://support.pega.com/discussion/list-view-search-and-select-ux-pattern

Constellation 101 Series

Enjoyed this article? See more similar articles in Constellation 101 series.