We have a requirement to search the data by hitting an External API. The search request fields populated on UI should have a an ability to mulit select the dropdown values and these need to be cascaded. For example Based on A multi selected values, B multi select fields need to be displayed. Is there an OOTB‑supported approach for cascading multi‑select dropdowns in Constellation?
We have a similar requirement multiselect cascading drop-down.
This is technically possible with couple of options,
- Declarative rules
- pyRefreshData
- How Form refresh works with Page List properties
if you’re looking to build the relationship for example: between Folders and Sub folders for Cascading drop-down, please use repeating views.
Thank you for the prompt response. We are in Pega infinity 24.2.2 and i don’t think pagelist form refresh works in this version. Diving more into our use case, in traditional UI-Kit the search fields with multiselect cascading dropdowns are typically created in a section, On click of search button calling an API to return the search results. In constellation we are thinking of two options
- Landing Page- Datapage to retrieve the search results and use prompted filters. But prompted filters is having a cascading multiselect issue between fields. Declarative rules and pyrefresh data might not work in this scenario
- Triage Case type- A new case type by implementing display search and select component. We will have to try if pyrefresh data and declarative rules works for this scenario. As search and select component page is also dynamic page not sure if we can cascade multiselect values from One search field to other search field
Landing Pages - there is a feature introduced in 25.1.1 for cascading dropdowns. I’m not sure if there is an alternative way to achieve in 24.2.x version
Hello @SHALINI_KOPURI
Based on your requirement, i believe you will have more control over the requirement when you go for a Triage case type rather than landing page. However, you have to check the allowed case count as part of the pega contract for your client.
In general,
If you are loading the table information from a pega DB table, Promoted filters field(s) data is generally aggregated based on the information you have in your table for that field(s).
If the data is loaded from an external system, then you don’t have the information upfront for that particular field and hence you cannot pre-populate the fields configured for your Promoted filters.
Let me give you an example of what i have implemented in 24.1 an year n half back.
We have MS GraphQL service which exposes Employee Profile information. We have implemented a search and select on the first screen of the case.
When user types in either name or phone number, we pass the information to data page and from there to the service with graphql providing contains and starts with criteria facilities. Depending upon the search criteria service returns the results and list is displayed on the UI and user will select one of them.
For the above scenario as its a text field user can type in text and search. If it’s a cascaded dropdown may be you can maintain a data type which contains these fields like Folder, Sub Folder. Implement search and select and with these Folder and SubFolder as cascaded search criteria (configured as Picklist) and when user select the search criteria and clicks on search, pass these values to the data page and call your service (provided your service has this ability to accept contains, starts with criteria like MS GraphQL)
This is just an idea to explore which i will also try from my end. This could be a starting point for your to explore as well
Will keep you posted
Regards
JC
@SHALINI_KOPURI this might help too.
Hello @SHALINI_KOPURI
I have implemented the requirement mentioned above by me in both Pega 24.2.1 and 25.1, specifically around cascading multi-select behavior with external API-driven search.
Approach that works (Search & Select in a Case Type)
I implemented this using a Search and Select pattern inside a case type, and it works reliably with some design considerations. However, you have to cross-check the allowed case count as part of the pega contract for your client.
Use Case Implemented
Two fields in Search:
- Employee Name (single select dropdown)
- Display: Employee Name
- Value: Employee ID
- Assets (multi-select dropdown)
- Display: Asset Name
- Value: Asset Tag
Cascading Behavior
- Based on selected Employee(s), the Assets dropdown is dynamically filtered to show only relevant assets.
- This is achieved by:
- Backing both fields with separate Data Types (e.g., Employee, Equipment)
- Configuring the Assets data source to depend on selected Employee IDs
Search Execution
- On click of Search, selected values should be passed to a backend integration.
Key Implementation Details
-
Abstract Class for Search Context
-
Created an abstract class to hold:
- Search fields
- Result fields
-
This acts as a clean contract between UI and integration layer
-
-
Using
pySearchPageName-
The Search and Select component automatically passes user inputs into a page (via
pySearchPageName) -
This page contains all selected search criteria (including multi-select values)
-
-
Data Page Setup
-
Created a Data Page:
D_GetAllRequests -
No explicit parameters defined
-
-
Data Transform as Source
-
Source: Data Transform (
LoadRequests) -
Inside this:
- Read values from
pySearchPageName-
Extract:
- Employee IDs
- Asset Tags
-
Pass them to another parameterized Data Page that calls the external API
-
- Read values from
-
-
Integration Layer
- Final Data Page invokes the external service with:
- Employee IDs (list)
- Asset Tags (list)
- Final Data Page invokes the external service with:
Why this works well
- Supports multi-select cascading
- Works with external APIs
- Keeps UI loosely coupled from integration
- Leverages OOTB Search and Select behavior instead of custom hacks
Landing Page Approach (Limitations)
I also tried implementing the same using a Landing Page with Promoted Filters (inspired by this thread):
Observations:
- Cascading between multi-select promoted filters seems to be not working properly
- Likely due to current limitations in how Promoted Filters are handled in Constellation
I am still looking into the landing page approach to make it work. Will keep you posted
Regards
JC
@JayachandraSiddipeta , Thank you for the detailed analysis. In the case type Search and Select component scenario, the user will not be selecting any data from the results. Instead, they need the ability to modify specific row-level values returned from an external API by using the Edit action on the Data Type.
Currently, we do not have an option to hide the Select radio button or Multi‑select checkbox based on the data reference property type created for this scenario. As a result, this approach may not provide an optimal user experience.
Exploring at the moment landing page promoted filters but as you mentioned cascading multi select dropdown values from field A to multi select drop down values field B is a challenge in this scenario
@MarcCheong This functionality works correctly for picklist fields; however, it does not work for cascading multi‑select (combo box) fields specifically on promoted filters or search and select component search fields scenario
If you are looking for CRUD operations on external data, then you can have a look at this post
See if you can adjust this with search and select on the case type. The post mentions about the landing page approach. But you need cascaded filters which currently seems a bit difficult.
Also a part of your requirement (kind of linked) was asked by another community member which might interest you or give you some ideas to get the juices flow in the mind
Your requirement is not straight forward, so you might have to stitch multiple things together to get closer to what you need.
Hope this helps
Regards
JC
Can you tell a bit more about what the user needs to search and select for and what the user tries to achieve? I am sure the user does not literally need a cascading multi select field per se. This helps to find the right pattern to use.