Almost everything in the ’26 user experience release adds something. This item removes something, and the removal is the point. Tables now fetch less data than they used to, which makes them faster for every user on every load — and, for a small number of applications, changes behavior enough that you need to know about it before you upgrade.
What it means
Through Pega Platform ’25, opening a table fetched every field on the underlying object, not only the ones the table displayed. That was a deliberate trade: pay the cost once, up front, so that an author adding a column later gets it instantly. The cost landed on the wrong person. Authors add columns occasionally; users open tables constantly.
Pega Platform ’26 reverses the trade. Fields corresponding to table columns are fetched only when they are actually in the table. Nothing else comes down the wire.
What it does
-
Faster first render. The time to show a table for the first time drops, because the payload is scoped to what is on screen.
-
Smaller responses. Less data crosses the network and less is held client-side, which compounds on wide objects.
-
A new author step. Adding one or more columns is now explicit: select them, then click Apply to retrieve the necessary new fields.
How it works
The new behavior is the default and needs no configuration. The only change in the authoring experience is the Apply click when you add columns.
The compatibility switch. Before this change, it was possible to create column heading fields calculated from fields that were never displayed. In ’26 those headings might not work by default, because the data they derive from is no longer fetched. Setting the Dynamic System Setting RETAIN_RD_COLUMNS_IN_DATA_API_CALLS to true restores the earlier behaviour.
What to remember
-
Calculated column headings are the regression to look for. If a heading is derived from a field the table does not show, it is a candidate to break. Inventory these before the upgrade, not after a user reports a blank header.
-
The DSS is a bridge, not a destination. Turning RETAIN_RD_COLUMNS_IN_DATA_API_CALLS on restores ’25 behaviour — and ’25 load times — across the board. Use it to buy time while you fix the affected columns, then turn it off.
-
The benefit scales with object width. Applications with wide Case or Data objects and narrow tables gain the most. Tables that already showed most of their fields will barely notice.
-
Set author expectations. The Apply step is a second of friction for the handful of people who build tables, in exchange for faster loads for everyone who reads them. That is the argument if anyone pushes back.
Technical documentation: Configuring tables