Tables and lists

Tables and lists

Use a table when displaying tabular data, or comparing data both vertically and horizontally. When comparing data is unnecessary, a repeating dynamic layout (RDL) is a better choice.

Best practices for tables:

  • Tables should extend to 100% of the available space.
  • Numeric cell data should align right, otherwise the data should be left-aligned.
  • Columns containing a single icon should be aligned to the center.
  • Column headings should always match the text alignment of the data in the column.
  • Columns should be presented in a logical order.
  • Primary data should appear in column 1. (In many applications, this will be a link to another object.)
  • Row actions — such as delete — should be in the last column.

Last updated: Jun 2017

What type of table or list do I use?

The generic Pega control for a table is a standard HTML table. Repeating data can also be shown in other formats.

  • Use a Table if there is a significant quantity of information to display, and/or a need to compare one or more properties of the items.
  • Use a Fat list if there is a significant amount of information to display, and users may need to compare no more than one property between items.
  • Use a Tree if you have a significant quantity of information to display, and this information is hierarchical with a parent-child relationship.

Depending on the type of information you're displaying to the user, more than one of these types may be appropriate, and designers should use their discretion to choose the best solution.

Last updated: Jun 2017

Mobile tables

Table controls are responsive, and on mobile devices they will reformat automatically to work for that form factor. The primary column from the table becomes the header for the item, and other columns in the table are listed with the labels on the left and values on the right.

Mobile table list example

Last updated: Jun 2017

List patterns

Lists as a container

A list can be the only item in a top-level (Default) container. For example, when the list is long, and/or has many columns. The primary action of a list should be in the upper right corner (usually “add”, shown as a plus icon). Use a tertiary button style for this. Individual items in a list are opened by clicking the primary column link. The list items should be added via modal dialog.

List as a container example

Tiny lists

When lists are inside of a container, but not the focus of that container, items should be added to the bottom of the list by using a tertiary button with a plus icon. In this case, the adding should be inline and not open a modal dialog. Tiny lists never use paging.

Tiny list example

Dedicated landing pages

A landing page is dedicated to displaying a list of items of a certain type. To add items to a landing page, use the primary action button in the page header, which can either launch a modal dialog or a new page. Otherwise, follow the list container pattern.

Dedicated landing page example

Case widgets

Case widget lists are often tiny, but hide a lot of complexity in the data objects they display. Items should be added to case widgets via a modal dialog that is launched from the upper right of the widget header by using a tertiary button.

Case widget example

Last updated: Jun 2017

Lists as a container

Adding, searching, and filtering

Simple - with an empty state

Simple list with an empty state example

Simple - Adding occurs via the “+” in the upper right corner

Simple list adding example

Complex - List with optional search and filters (search is active). There is a primary add action in the far right of the header, and a “More” menu to allow access to more actions directly to the left.

Actions that apply to an entire list should be shown in the header (searching, filtering, adding, etc.). Actions that apply to specific items should be shown on the row (delete, edit an item, etc.).

Complex list example

Mobile - On mobile devices, the various columns are shown in a list. All actions and configurations beyond the primary action are shown in a “more” list.

Mobile list example

Selecting items

Selecting a single item in a list: Clicking a row selects it. Clicking a row again unselects it.

Single select example

Selecting multiple items from a list: Use checkboxes to select items. Clicking on the row should also activate the check box. In the header row, include a checkbox for “select all”.

Multi-select example

Bulk actions: If a user can perform bulk actions on selected items, show the total count selected next to the bulk action button. The bulk action button should be hidden until two items are selected.

Bulk actions example

Mobile: A mobile list does not have a column header row. “Select all” should appear as a button above the list if applicable. Bulk actions should be treated the same as on the desktop, where the number selected is displayed next to the bulk action button.

Mobile example

Expanding rows

To expand an item in a list, the user clicks an arrow. The arrow is to the left of row content, but to the right of any check boxes.

Expand list item example

The expandable arrow has a hover style to indicate that it is an action.

Hover example

Information shown in the expanded pane should have a gray background to indicate that it is secondary.

Secondary example

Expanded panes can contain tiny lists. These lists should be displayed with the gray secondary background.

Tiny list example

Expanded panes can also contain container lists. In this case, the container list should be displayed in a white container placed on top of the gray secondary background used for the expanded pane.

Expanded pane example

Last updated: May 2017


Types of paging

A few types of paging come out of the box with Pega applications. Most UI patterns need one of three varieties: “Page 1,2,3”, “First X Results”, and “Progressive”. Other paging types should generally be avoided.

  • Page 1, 2, 3 — “Traditional” paging, and a default choice when no other type is a perfect match. Example: Search results.
  • First X results — Use when filtering is not a major use case, and for fitting lists in small spaces. Example: Attachments on a case.
  • Progressive — Use when filtering and browsing is the primary action, and there is no content under a list on the page. Also known as lazy load. Example: Worklist landing page
  • No paging — Lists should have paging, except when a user is actively adding each row in a list, or if a user is adding items to a pre-existing list that will never be more than 20 items.

Landing and dedicated pages

Landing pages should show the first 20 items by default and use progressive paging, even when the user filters on these results. When creating an application for mobile, consider having 10 options per page to reduce load time.

Landing page example

Dedicated search pages

Dedicated search pages return a set number of results and initially this page should not show any results. The count of results should appear on the upper left of the grid, and the paging should appear on the upper right. Use Page 1, 2, 3 with 20 results per page, and include a total count.

Search page example

Workflow search

If search is needed inside a workflow, or if a search area is above other content, results should be limited to 10 items per page. This shortens the content and makes it easier for users to navigate below it. Use Page 1, 2, 3 and include a total count.

Workflow search example

Case widgets

Case widgets are optimized for small spaces. The most important items in a case widget should be shown first. Depending on use case, items are sorted by role (like below), date, or other relevant filters. More items in the list can be viewed in a modal dialog. When displaying this list in the modal dialog, follow the pattern of a landing page. Use the First X results pattern with 5 results per page. The “Show all” link should open a modal dialog.

Case widget example

Fat lists

Fat lists, a list with more than one line of content, present a unique challenge because they have varying row heights. In general, follow the pattern appropriate for where the list is being used (landing page, search, workflow, case widget, etc.) and adjust the results per page as needed. For example, if lists items are very tall, consider limiting the list to 10 items instead of 20. Appropriate “per page” values are: 5, 10, 15, 20, and 50.

Fat list example


The same principles apply to mobile views. If there is no content under a list, use progressive paging. If there is content under a list that the user needs to scroll to, use Page 1, 2, 3 paging.

Mobile example

Last updated: Jun 2017

Get the files

Want to begin working with the Pega Design System? Download the vector assets below.

Download design files

Last updated: May 2017

Next: Case headers