Constellation gives us a rich set of table features out of the box — sorting, filtering, grouping, promoted filters, personalized views, search, and export. Individually, they’re well documented. But in practice, the real UX impact comes from how you combine them. This article shares patterns I’ve seen work across partner delivery teams building real applications on Constellation.
1. Start with the Resting State
Before configuring a single feature, answer one question: when a user lands on this table for the first time with zero interaction, what should they see?
That “resting state” is the product of two decisions: your default sort order and your promoted filter defaults. Together, they define the table’s personality.
Example: In a financial services onboarding app, the pending applications table was default-sorted by Risk Score descending. Combined with an “Assigned To” promoted filter pre-set to the current operator, each underwriter landed on a table showing their personal queue ranked by risk. No clicks required. That combination eliminated the need for a custom dashboard.
The principle: A well-designed resting state means most users never need to touch the sort or filter controls at all. Design for the 80% case.
2. Layered Filtering: A Decision Framework
Constellation gives you three filtering layers. Here’s how I think about when to use each:
• Promoted Filters (top of table) — for the 3–5 fields your users filter by every single day. Status, priority, date range, assigned team. These are always visible, zero clicks to reach. Promote too many and you create toolbar clutter; too few and users are constantly diving into column menus.
• Column-Level Filters (three-dot menu) — for the long tail of ad-hoc filtering. Every column gets this for free. Power users who need to filter by a field you didn’t anticipate can always get there.
• Global Search (magnifying glass icon) — for the “I know what I’m looking for but not where it is” moment. Freeform text across all visible columns simultaneously.
A good heuristic: if more than 30% of your users filter by a field daily, promote it. If less than 10%, leave it to the column menu. For the 10–30% band, lean toward promoting if the filter is used in high-stakes or time-sensitive tasks (e.g., filtering by urgency in a triage queue) — task criticality matters more than raw frequency in those cases.
*******************************
The Client-Side Limitation — Know This Before You Ship
Promoted filters only filter data already loaded on the client. They do not trigger backend API calls.
This is the 1 surprise I see on delivery teams. If your data page returns 10,000 records (already double the documented soft limit of ~5,000) and the user applies a promoted filter, Constellation filters those 10,000 in the browser. It does NOT call the backend with new parameters.
For use cases that require server-side filtering (e.g., switching between operators to view different users’ cases, or searching a dataset too large to load upfront), the recommended pattern is:
• Use a parameterized data page with explicit UI controls (dropdown, text field) that trigger a data page refresh on value change.
• This is a different architectural pattern from promoted filters — it requires designing the data page to accept and respond to parameters.
This distinction is critical for high-volume applications. Promoted filters are for refining a loaded dataset. Parameterized data pages are for querying a different dataset.
Additional Considerations:
Technical note: For a Data Page to support server-side filtering via UI controls, it must be configured as queryable — the “Allow querying any column” setting must be enabled. Filter values are passed to a Request Data Transform on the Data Page before the query executes. This is a design-time configuration decision, not a runtime toggle.
Configuration trap: Avoid setting “Reload once per interaction” on the Data Page for non-paginated tables. While it seems like a way to keep data fresh, it forces a new backend query on every user interaction and defeats the client-side caching behavior that makes promoted filters fast. If freshness is a requirement, use pagination or a scheduled data page refresh instead.
Monitoring note: Once deployed, use PDC (Pega Diagnostic Cloud) to flag slow-running queries or high-frequency data fetches on tables. Teams that ship promoted filters on datasets approaching the ~5,000-record threshold often discover the issue through PDC alerts before users formally report it.
******************************
3. Grouping as Storytelling
A flat table of 200 rows is a data dump. The same 200 rows grouped by Status — showing Open: 45, In Progress: 80, Resolved: 75 — tells a story about workload distribution at a glance.
Grouping changes the cognitive model of the table. Users stop scanning individual rows and start reading categories. This is especially powerful for:
• Queue management: Group by Priority, sort by Created Date ascending within each group. Users see the oldest high-priority items first — classic triage.
• Portfolio views: Group by Region or Product Line. Managers see their territory’s breakdown without needing a separate report.
• Complex data hierarchies: The Constellation 101 article on Complex Data Visualization demonstrates two approaches — nested repeating layouts (more modern/visual) and tables with grouping (more classical, full sort/filter/CRUD). The table-with-grouping approach is often underestimated; the OOTB features that come with it are substantial.
4. Personalization: Build One Default, Let Users Own the Rest
Personalization lets end users save their own table configurations — column visibility, sort order, filter values, grouping — as named views. It works across Table, Gallery, and Timeline formats.
This is where table design philosophy meets user empowerment:
• The developer’s job: Build one excellent default view that serves the broadest use case well.
• The user’s job: Customize from there. An underwriter saves “My Queue – By Risk Tier.” A manager saves “Team Overview – By Assignee.”
Governance note: Personalized views are stored as System-User-Grids data instances. When you update the underlying Insight or List View definition in a release (add/remove columns, change data source), existing user-saved views may not reflect those changes. Users may need to discard and re-personalize. This should be part of your release communication strategy. Consider mentioning it in release notes or in-app messaging.
5. Complex Data Capture: When Tables Are Inside Forms
Tables aren’t just for landing pages and Insights. They’re also the primary pattern for capturing repeating data inside a case — line items, dependents, addresses, documents.
The decision point: inline editing vs. modal editing.
• If each row has 2–4 simple fields (Name, Quantity, Price) → inline editing in the table row is natural and fast.
• If each row requires 5+ fields, conditional logic, or validation → modal editing. The modal opens a full form in a dialog overlay for add/edit. Design the modal View as a standalone form — field groups, helper text, validation — it should make sense on its own.
Infinity ’25 enhancement worth knowing: Before Infinity '25, modal dialogs for editable tables could not natively handle pre-population of defaults or post-capture derived value calculations — teams typically worked around this with embedded sections and JavaScript hacks. In '25, User Actions as the data source for modal dialogs unlocks a clean, supported lifecycle: pre-processing Data Transforms populate defaults before the user sees the form; post-processing Transforms calculate derived values on save; and input validation runs inline. If your team is on '24 and feeling that friction, this is a concrete reason to evaluate '25 — not just a nice-to-have.
Gallery as an alternative: Don’t forget that the same List View data source can be rendered as a Gallery (tile cards) instead of a Table. Galleries are ideal for visual scanning — product catalogs, team rosters, equipment inventories. If your data has a strong visual identity per item, Gallery may serve users better than rows and columns.
6. Putting It All Together: A Configuration Checklist
When configuring a new table in Constellation, I walk through these decisions in order:
1. What’s the resting state? Define the default sort and any promoted filter defaults. This is the table’s personality.
2. What are the top 3–5 filters? Promote those. Leave the rest to column-level menus.
3. Does grouping tell a story? If so, configure a default grouping. If not, leave flat.
4. Should users personalize? For data-heavy operational tables, almost always yes. Enable it.
5. Is the data volume client-safe? If >5,000 records, think carefully about data page constraints and whether promoted filters are sufficient or whether you need a parameterized data page.
6. Table or Gallery? If data is visual (products, people, equipment), consider Gallery. If analytical (transactions, audit logs, queues), Table.
Over to You
I’m sharing these patterns from work across partner delivery teams, but the best insights come from the community. I’d love to hear:
• What’s your promoted filter limit? At what point do you move from promoted filters to a dedicated search screen? I find 5 is the threshold, but I’ve seen teams push to 7–8.
• Has anyone used Gallery format for a use case that surprised them? I’ve mostly seen it for catalogs and rosters — curious if anyone has found creative applications.
• How are you handling the personalization governance challenge? When you update an Insight definition in a release and users have saved views that don’t reflect the changes — what’s your communication strategy?
• Have you ever had a team ship promoted filters against a dataset that grew past the client-side threshold post-launch? How did you detect it — user reports, PDC, or load testing? What was your remediation path?
If you’re interested in this topic, I’ll be on the UX Expert Circle panel discussing tables and complex data capture — bring your questions and war stories.
