When tables aren't enough: Building search-first experiences on Constellation landing pages

User Experience Knowledge Share
, ,
1

WHEN TABLES AREN’T ENOUGH: BUILDING SEARCH-FIRST EXPERIENCES ON CONSTELLATION LANDING PAGES

One of the most common requirements in Constellation delivery is the search screen: a landing page where users enter criteria, hit search, and see filtered results from an external or internal data source. It sounds simple. In traditional UI, it was. In Constellation, it requires a different mental model — and the community threads on this topic tell me a lot of teams are hitting the same walls.

This article walks through the patterns I’ve seen work, the gotchas that trip teams up, and a decision framework for choosing between them.

THE PROBLEM: TABLES LOAD EVERYTHING BY DEFAULT

When you configure a List View on a landing page, Constellation fetches the data page and renders all results immediately. There’s no OOTB configuration to say “don’t query until the user searches.” For small datasets, this is fine. For tables backed by APIs returning thousands of records, it creates two problems:

  • Performance: an unconstrained initial query hits the backend unnecessarily and can be slow.

  • UX confusion: users see a full result set before they’ve specified what they’re looking for, which undermines the search metaphor.

This isn’t a bug — it’s how Constellation’s List View component was designed. List Views are optimized for operational tables (work queues, case lists) where showing all data on load is the right default. But when your use case is “search first, results second,” you need to work with the architecture, not against it.

PATTERN 1: CONSTRAINED DEFAULTS ON THE DATA PAGE

When to use: your data source supports parameters and you can define a sensible default scope.

Instead of loading everything, constrain the data page’s default parameters so the initial query returns a small, meaningful result set. For example:

  • A claims search defaulting to “last 30 days, current operator”

  • A customer lookup defaulting to the operator’s assigned region

  • A transaction search defaulting to “today”

Promoted filters then let users broaden or change the scope. Because your data page supports advanced query, changing the promoted filter values triggers a new API call with the updated parameters. The key is that the initial load is already constrained — users see a useful, scoped result set, not an empty screen and not an overwhelming full dump.

Advantage: pure OOTB configuration, no custom components, and the UX communicates “here’s what’s relevant now, refine from here.”

PATTERN 2: EMPTY LIST ON LOAD

When to use: you genuinely need a blank slate — the user must search before anything appears.

The Constellation 101 article “Empty List on Load in Constellation Landing Page” documents a technique using clipboard properties to suppress the initial data page query until a filter value is provided. The result is a landing page that shows promoted filter fields at the top and an empty table below, which populates only after the user enters search criteria.

-- CAUTION –

This approach relies on clipboard-level properties to intercept and conditionally control the data page invocation. While it works as of '24 and '25, it uses internal implementation details that could change in future releases if Pega modifies the component’s architecture. Before committing to this pattern in production, verify with your Pega version and consider whether Pattern 1 (constrained defaults) can achieve a similar UX with less risk. If a constrained default scope can satisfy the business requirement, that is the lower-risk path.

PATTERN 3: CASE-BASED SEARCH FLOW

When to use: search requires complex input (multiple fields, date ranges, conditional logic) that exceeds what promoted filters can support.

Create a lightweight case type that serves as the “search transaction.” Step 1 collects the search criteria in a form. Step 2 displays the results in a table sourced from a parameterized data page using the captured criteria. This gives you the full power of Constellation’s form capabilities (field groups, validation, conditional visibility) for the search input, and the full power of List Views for the results.

This pattern is particularly useful for:

  • Search across non-Pega systems — a Connect REST sourcing the data page with parameters from the search form

  • Audit and compliance scenarios where you want to log every search as a case instance

  • Complex multi-field searches with interdependent fields (e.g., selecting a Country changes the available Region dropdown)

Advantage: full form capabilities, full table capabilities, no workarounds. The trade-off is it’s a case, not a landing page widget, so it has a case lifecycle overhead.

PATTERN 4: CUSTOM DX COMPONENT

When to use: none of the above patterns meet your requirements and you need full control over the search/results lifecycle.

Build a custom DX component that manages its own state: renders search inputs, makes API calls on submit, and displays results in a custom table. The Constellation UI Gallery on GitHub provides a foundation. Note: in Pega Platform '25, the new DX Library further simplifies managing and importing custom components directly from GitHub, which reduces the setup overhead if you’re already on '25. This gives you total flexibility but comes with the highest development and maintenance cost.

Recommendation: exhaust Patterns 1–3 before reaching for this. Every DX component is custom code you’ll maintain through upgrades.

DECISION FRAMEWORK

  1. Can you define a sensible default scope?
    Use Pattern 1 (constrained defaults). This covers the majority of cases.

  2. Must the table be literally empty on load?
    Use Pattern 2 (empty list technique). Accept the implementation risk.

  3. Is the search input complex (5+ fields, conditional logic, validation)?
    Use Pattern 3 (case-based search flow).

  4. None of the above fit?
    Use Pattern 4 (custom DX component). Budget for maintenance.

OVER TO YOU

Search screens on landing pages are one of those requirements that seems straightforward but forces you to think about Constellation’s architecture differently. I’d love to hear:

  • Which pattern are you using? And what edge cases have you hit?

  • Has anyone found a cleaner “empty on load” approach that doesn’t rely on clipboard properties?

  • For teams using Pattern 3 (case-based search), how have your users reacted to the “search is a case” metaphor?

RELATED READING

• Empty List on Load in Constellation Landing Page — Constellation 101
• REST CRUD Actions in Constellation — Constellation 101
• Advanced Search – List Views vs Insights — Constellation 101
• List Views — Constellation 101
• Using Promoted Filters to Help Refine Your Data Search — Constellation 101

1 Like
2

A clear solution is to use a lightweight case type for the search instead of relying on a landing page table. In Constellation, List Views load data as soon as the page opens, so they are not a good fit when the business wants users to search first and see results later. Build a simple case where the first step captures search fields and the next step shows the filtered results from a parameterized data page. This gives you proper validation, conditional fields, and clean control over when the backend call happens. It also avoids risky workarounds and fits better for complex searches or external system lookups

3

I think you are exactly right when the complexity merits this. Pattern 3 is often overlooked. Thank you for sharing.

4

Thanks for this article. I think it is part of a bigger phenomena. Most of us when dealing with list of objects automatically choose tables. Tables are great when you have, well tabular data. But there are use cases when you have list of objects but there are better solutions.