Entity list page filters

An Entity list page can require a selected Statement to be true for every record in its results. Use this to give one record type separate pages such as Active customers and Former customers, each with its own table and menu entry. The records stay in the same Entity Definition.

The Statement belongs to the page. The selected Table Surface still controls columns, available filters, and sorting. Two pages can share a table or select different tables without sharing their page filters.

Configure two pages

1. Open the Entity Definition and create two Statements describing the subsets. For example, on a record type with a Yes/No field named Active, use Active = TRUE and Active = FALSE. Enable client exposure for both Statements; only exposed Statements from this definition are available for selection.
2. Open Surfaces and the Entity list group. Create or clone a page for each subset, giving each page a distinct name and stable key.
3. Open the page’s Actions > Edit configuration. Choose its Statement filter and the table it should render, then save. Repeat for the second page with the other Statement. Cloning copies the filter, so change the clone’s selection when it represents a different subset.
4. In Administration > User menus, add two Data Explorer entries. Select the same Entity Definition and a different Entity list page for each entry. See User menus.
5. Open both menu entries as a user who can view the records. Check their rows and totals, then try search, an additional filter, another results page, and clearing the user filters. Each page must keep its configured subset.

If records with an empty Active value should belong to a subset, include that case explicitly in the Statement; equality with FALSE does not match null.

What users can change

Search, user filters, and saved or shared views further narrow the page’s results. They are combined with its Statement using AND. Even an OR group in a saved view cannot add records outside the page’s subset. Clearing filters does not clear the page’s Statement.

The filter applies before counts and pagination, including lazy Tree child requests. Tree View can retain accessible ancestors as context for matching descendants; an ancestor shown for context need not match the Statement itself. Data Explorer export includes the Statement applied by the latest loaded table query. Reload the table after changing its page configuration before exporting. Manual Order moves are unavailable while the page has a Statement filter.

Change or remove the filter

Clear Statement filter and save to remove the page restriction. Resetting the page configuration also clears it. Pages without a selected Statement keep their existing behavior.

If a selected Statement is deleted or is no longer exposed to clients, the page reports a configuration error rather than showing an unrestricted list. Choose another exposed Statement or deliberately clear the setting to repair the page. Editing the Statement’s expression changes the subset on the next query.

Access and other screens

A page filter does not grant or replace record permissions. Configure Entity access whenever records must be protected across the application. Other pages, direct record API queries, and reference pickers keep their own query scope and permissions.

For automation, replacement requests, and portable YAML, see Entity list page API.