I have a requirement where there is one Search case type. This will be screen flow where in the first screen I have some textbox mainly the filter criteria suppose first name , last name and dob. On click of Next button, it will show the search results based on filter criteria in a tabular format. In the search results, I will be having the case ID link against each record and it will be link to that particular work object so on clicking of the Case ID link, the WO will be open.
Now, linking a case ID for a repeating view can be achieved by including the OOTB Case Reference field type. There are some customization options available when it comes to how the case ID is shown but your requirement falls within these boundaries.
@ShreyaG3 Before deciding the design, the key point is to understand what the search is meant to achieve in the business flow. A separate Search case type is not always necessary.
If the search is part of the current case journey, then the recommended approach is usually to place it as a stage/step within the existing case type. This works well for scenarios like duplicate case search or linking other cases from other case types to current case where the search results directly support the ongoing case.
If the search is just a reusable lookup utility, then Insights are actually a strong fit for this kind of search, often better than a generic landing page when the goal is to find and open existing cases. For a pure search/list experience where the user enters filter criteria (e.g., First Name, Last Name, DOB) and then opens the selected case from the results, an Insight with a list view and promoted filters is often a better fit than a general landing page.
Insights are designed for listing, filtering, sorting, and opening cases. They expose promoted filters for search criteria and when the results include the required identifiers (pyID, pzInsKey, pxObjClass), the Case ID column can be rendered as a link that opens the target work object.
This Insight can be created as a reusable view, which can then be embedded anywhere in the application wherever the search is needed
Initially we opt for Insight and Table list view but the filter for date was coming as a range not single select date. Also, while selecting the date the year dropdown was only last 10 years. So suppose the DOB I wanted to search is around 1950 so I have to select every 10 years to go back ffrom current year to back dated years. SO we opt for Search case type.
@ShreyaG3 The date-range filter and the 10-year dropdown limitation are UX constraints of the promoted filter’s default date component, not blockers for the overall pattern. You can address these while still keeping the Insight and avoiding a separate Search case type.
You can keep the Insight + list view as the core search screen and customize the date filter so that the DOB is a single-date picker, not a range and the year dropdown allow full historical range (e.g., going back to 1950 or earlier), not just the last 10 years.
This is typically done by defining a custom property for DOB (e.g., DOBDate) as a Date type on the queryable data page / report definition. On the Insight, using a custom filter component or a section-based filter form instead of the default promoted filter date widget. Configuring the date picker to Allow single date selection and Support a wider year range (by configuring the year list or using a custom input).
In Constellation, you can use a filter form section with your own UI controls (text box, date picker, etc.) and pass those values to the data page / RD as parameters.. Bind that section to the Insight or embed it above the list view.. Keep the rest of the Insight behaviour (table, sorting, grouping, opening cases). This keeps the search as a reusable view that can be embedded on a landing page or inside a step of an existing case or on a portal or dashboard.
A separate Search case type is only worth it if the search itself needs to be tracked as a business process (audited, assigned, resumed later) or if you need complex multi-step workflows around the search (e.g., approvals, notes, attachments tied to the search) or if you need advanced orchestration that cannot be expressed cleanly in a data page / view.
I agree with @RaviChandra recommendation. If the challenge is related to Date filter for the user to select before 10 years (For example: Date Of Birth), it would be good to work with your Account Executive to raise the feedback request to the Product team. Single select for the Date filter can be achieved if you can provide the 24 hour window.
If the case type has specific properties, then you may have to duplicate the properties in your search case type or add the properties to Work or layer up to support the search case type. You might end up creating different Data Pages with different associations to support business needs which can be seamless through Insights.
