The grid shows one response, and the endpoint decides its size

A grid without paging attributes displays the data from a single call to its inbound endpoint. Workday's grid reference says that by default the grid "fetches as much data as the client can handle, without pagination", but it can only show what that one response contains. Workday REST collection endpoints return 20 items when you don't pass limit and at most 100 when you do. So a grid of workers stops at 20, or at 100 once someone adds ?limit=100, even though total in the same response says there are thousands.

Workday's REST pagination page notes that some REST APIs raise the maximum to 1,000, and nested prompt endpoints default to and cap at 1,000. Graph API queries also default to 20 rows and cap at 100 (Pagination of Graph API Query Results). WQL is different: the limit parameter accepts up to 10,000 rows per page.

The fix depends on the page type, because paging works only on view pages.

On a view page: pagingInfo for endpoints that page

pagingInfo tells the grid which endpoint to call again for the next page, where the total is and where each page's rows are. All three attributes are required:

{
  "type": "grid",
  "id": "workerGrid",
  "label": "Workers",
  "rows": "<% workersEndpoint.data %>",
  "rowVariableName": "w",
  "pagingInfo": {
    "endPoint": "<% endpoints.workersEndpoint %>",
    "rowCount": "<% workersEndpoint.total %>",
    "data": "<% workersEndpoint.data %>"
  },
  "columns": [
    {
      "type": "column",
      "columnId": "nameColumn",
      "label": "Worker",
      "cellTemplate": { "type": "text", "value": "<% w.descriptor %>" }
    }
  ]
}

The endpoint's url must read the grid's paging variables. The grid sets them on each request, and each grid has its own:

{
  "name": "workersEndpoint",
  "baseUrlType": "workday-staffing",
  "authType": "sso",
  "url": "<%
    var limit = pagingVariables.limit ?: 30;
    var offset = pagingVariables.offset ?: 0;
    '/workers?limit=' + limit + '&offset=' + offset;
  %>"
}

Three details to get right, the first two from Workday's grid reference:

  • pagingVariables.limit and pagingVariables.offset are strings, and empty on the first call. Give them initial values with ?: as above, or the first request goes out without them.
  • rowCount must be the full count, normally total from the response, not the length of data. The grid uses it for the count at the top and to size the scroll bar. Bound to data.size(), it reports only the rows already fetched as the total.
  • The url must actually contain limit and offset. A URL that ignores the variables returns the first page every time, so scrolling repeats rows instead of adding new ones.

Keep limit within the API's maximum. Asking a 100-maximum endpoint for 500 doesn't get you 500.

On a view page: autoPaging for one large, fast response

autoPaging is for an endpoint that returns a lot of data in a single call and has no paging parameters of its own. With "autoPaging": true, the grid shows the first 50 rows and calls the endpoint again as the user scrolls down. Workday advises against it for slow endpoints, because scrolling can trigger the call several times. autoPaging and pagingInfo are mutually exclusive. For endpoints that take limit and offset, Workday says to use pagingInfo.

WQL behind a grid

A WQL endpoint pages the same way, through the limit and offset query parameters on /data. Workday's WQL pagination page adds two behaviors. The first query builds a cache that later pages read, and that cache lasts only for the user's session, up to 30 minutes. And the LIMIT clause inside the query is separate from the limit parameter: the clause caps the total rows, the parameter sets the page size. A LIMIT 100 in the query string stops the grid at 100 however the paging is configured. WQL past 500 rows covers the WQL side in detail.

Why onLoad transformations stop after the first page

If you reshape the grid's data in the page's onLoad handler, the reshaping covers only the first page. Workday's PMD scripting reference is explicit: onLoad fires only on the initial load. When a grid uses pagingVariables, onLoad doesn't run again for later pages, so rows from page two onward arrive in the endpoint's raw shape.

Do per-row shaping in the cell templates instead, which are evaluated for each row as it renders. Or ask the endpoint for data that's already in the shape you need, through WQL column selection or a report.

Edit grids can't paginate

Workday's grid reference states that pagination options for large tables don't apply to edit grids, and both pagingInfo and autoPaging are view-page-only. An edit grid holds every row it will submit, so the fix is to load fewer rows:

  • Filter at the source, so the edit grid contains only the rows this user should change: their team, one cost center, open items only.
  • Split the work. Put a paged view grid first with row links or a selection, then an edit page for the chosen subset.
  • If the change applies to many rows with the same values, don't use a grid for the edit at all. Collect the values once and let an orchestration apply them to each record.

Large edit grids also run into the platform's other limits: a 25 MB maximum endpoint response, 24 seconds per endpoint, 60 seconds per page request, and the script CPU and memory limits when cell templates do work per row. See the Extend script CPU and memory limits.

Checking that every row arrives

Compare the grid against the source total, not against what looks plausible.

  1. Read total from the endpoint response for the same user and filters. The grid's count at the top should show the same number.
  2. Scroll to the bottom. The last row should be the last item in the source's order. Workday REST pagination sorts by ascending instance ID unless the service supplies its own sort.
  3. Spot-check for duplicates at page boundaries, such as rows 30 and 31 for a limit of 30. A repeated row means offset isn't reaching the URL.

Sources checked