I am seeking guidance on implementing a UI requirement in Pega Constellation and would appreciate insights or recommendations from the community.
Business Requirement:
Users must select a participant from a list of records.
The list should be displayed in a table (grid) format.
Single‑selection only, using a radio button per row.
Selection must be conditionally disabled for certain records based on business rules (for example, participant role).
Current Implementation:
The Search and Select component is currently used, as it aligns well with the single‑select and search experience.
However, the component does not provide an out‑of‑the‑box capability to:
Disable selection (radio button) for specific rows
Apply row‑level enable/disable logic based on record attributes
Challenge: From both a UI/UX and business rules perspective, users should be able to clearly distinguish:
Which participants are eligible for selection
Which participants are not selectable (and ideally understand why)
Given the limitations of the Search and Select component in Constellation, we are looking for alternative design approaches that remain aligned with Constellation best practices and avoid legacy UI patterns.
Questions to the Community:
What alternative UI patterns or components would you recommend in Constellation to support this requirement?
Is pre‑filtering records to exclude ineligible participants considered a best practice in such cases?
Are there recommended ways to visually represent non‑selectable records (for example, informational rows, read‑only indicators, or validation‑driven approaches)?
Has anyone implemented a similar requirement and can share their approach or lessons learned?
Any suggestions, design patterns, or practical experiences would be greatly appreciated.
Yes, if possible. It’s better to filter down the results upfront and this will avoid the confusions to the users.
The role can be added as part of Search and Select filter option to narrow down the list instead of showing as disabled rows in the the tabular column.
Hello @Maitri Good to see your message after long time. Hope things are well at your end.
There is no straight-forward approach for your requirement OOTB to my best knowledge. However, if we can play around with a DT and few When rules, we should be able to achieve this.
Below are the steps you can follow in two parts.
Data Setup
For the flow action where you want to display the table, create a pre-processing DT and get all the records from DB/external system which you want to display using a data page and copy them to an embedded pagelist on your work page. This embedded pagelist should be of the same class as your source page list.
Ensure that you have boolean fields like “IsSelected“ and “NotEligible“ in your data class.
While copying the data from your source data page to your embedded list, check the condition on each record for Ineligibility and mark the field “NotEligible“ on that associated record as true.
Create a when rule “IsNotEligible“ in your data class and check for the NotElible field to be true.
Create a when rule “IsAlreadySelected“ in your data class and check for condition like @countInPageListcountInPageList*(true,@pxGetParentListProperty“IsSelected”,* @pxGetParentListProperty*(StepPage))==1*
Create a when rule “IsCurrentSelection“ and check for field IsSelected to be true.
Create a when rule “NotEligibleForSelection“ and add logic like (4 OR 5) AND 6
UI Setup
Setup the embedded pagelist on your view as table and make it as editable and setup the IsSelected field and other fields of your choice to display. If there is a reason for selection ineligibility show it up here so that user is aware of it.
Ensure that you setup the adding, editing, deleting and reordering as Never for the table.
Except the IsSelected field, you can make the other fields to display as readonly for better UI look and feel.
For “IsSelected“ field add a disable condition as the “NotEligibleForSelection“ when rule.
If you follow the above steps, then the embedded list is shown with checkboxes for each record. For the ones which are not eligible for selection, you will see disabled checkbox and enabled for others. When user selects any one of the enabled checkbox, the other active checkboxes would be disabled giving it a feel of single selection.
When you unselect the already selected one, all the disabled ones will be enabled again giving the user chance to select another one. The default ineligible record checkbox would still remain disabled as usual.
The pitfall of this approach is that you have to copy the data workpage. Once you done selecting the record you want you can remove the other unselected records from the list on post processing.
The approach mentioned by @RameshSangili also works perfectly by default, however if there is a strict requirement for you to show the ineligible records as well in the list, then you can follow this approach. Depends again on the business requirement.
Below is a working version of this POC.
Hope this helps.
Would love to hear from other community members for any alternative approaches.