Summary

The Search and Select component in Pega Platform™ '25.1.1 is a Constellation User Interface (UI) pattern that lets users find and choose data objects/records (customers, cases, providers, etc.) from various sources within an app. It replaces manual UI construction (action sets, custom tables) with a consistent, system-generated experience — search fields, buttons, and result displays are auto-generated based on configuration.  

Typical setup involves: 

• Data configuration: a data transform on the "Search and select" Data Page handles parameters. 

• Case type integration: a data reference field on a Case Type sourced from a specific Data Object. 

When a Search and Select component is configured with multiple search groups backed by external REST data sources, records sharing the same pyGUID may not be recognized as identical selections across different search groups.

Issue

Identical pyGUIDs are inconsistently recognized across different search groups, causing discrepancies in selection behavior. 

Steps to reproduce

1. In Dev Studio create data object. 
2. Use a List Data Pages to display the search results. 
3. Configure a Common record identified by pyGUID. 
4. Create a Multi-Select data source (data reference).
5. Use with a Search and Select modal with multiple search groups 
6.  Result: If selected in one group, it is not selected in other groups.  Expected: Records with the same pyGUID should be consistently recognized across all search groups, preventing duplicate selections. 

Root Cause

This occurs because the Search and Select component generates unique row identifiers (internal $KEY values) based on all parameters configured in the backing Data Page, not just the pyGUID. 

Example: 

• Search Group A generates: $KEY = "GUID123|CategoryA|Personal" 

• Search Group B generates: $KEY = "GUID123|CategoryB|Business" 

Although both have the same pyGUID (GUID123), different composite keys are created, preventing duplicate detection. 

The Data Page serving the Search and Select component was configured with multiple parameters (for example, pyGUID, SearchCategory, AccountType). The component treats all parameters as part of a composite key when generating unique row identifiers.  

As a result, even though records represented the same entity (same pyGUID), they were assigned different key values based on varying parameter combinations, causing the system to treat them as distinct records rather than duplicates.

Solution 

1. Update Data Page Configuration: 

1. Navigate to the Data Page definition. 
2. Remove all parameters except pyGUID. 
3. Save the Data Page. 

2. Refresh Dependent Data Types: 

1. Open the data type used in the Search and Select configuration. 
2. Save and refresh to pick up the updated parameter signature. 

3. Test Duplicate Detection: 

1. Select a record from Search Group A. 
2. Switch to Search Group B. 
3. Verify that the same record (matching pyGUID) appears as already selected. 

Further Troubleshooting to fix partial record details displays

After simplifying the Data Page to use only pyGUID as a parameter, selected record details may not fully populate in the display table.  

Three approaches can address this: 

Option 1: Lookup Data Page 

• Configure a lookup Data Page that retrieves the full record from the external REST service using pyGUID. 

• Best for low-volume selections. 

• Performance consideration: One API call per selected record. 

Option 2: Caching Strategy 

• Implement a node-scoped Data Page to cache search results. 

• Retrieve selected record details from cache instead of repeated API calls. 

• Best for high-volume selections (for example, Select All functionality). 

• For more information, see Caching Strategy for Pega’s Search and Select. 

Option 3: Copy-on-Select 

• Configure the data reference to copy the full record on selection. 

• Set data reference mode to Copy (instead of Reference). 

• Reduces external API calls as full record is copied into the case. 

Validation: 

• Ensure self-referencing properties and alternate key configurations align with the unique identifier strategy. 

• Confirm response data transforms correctly map the unique identifier from external API to pyGUID. 

• Verify no additional transformations modify or concatenate the pyGUID value. 

Using the above steps, users should encounter no further problems when carrying out the below checklist: 

• Select record in Group A, verify selection persists in Group B 

• Use Select All functionality, verify no duplicates appear 

• Validate selected record details display correctly 

• Test performance with 50+ simultaneous selections if using the lookup approach 

References

Search and select from an external data source 

Caching Strategy for Pega’s Search and Select 

Configuring reference field as search and select 

Create new records without leaving the current form 

Filter, group, and manage columns in Search and Select results 

Search and Select forms now support complex field types 

Search and Select and Reset /Clear button behaves incorrectly