Worklist

A worklist fits when the set of items is already defined by the task and the user's job is to work through it: purchase requisitions waiting for a buyer, documents with a missing field, deliveries to confirm. Processing usually means opening an item, reviewing it, and then completing it or handing it on.

The decision criterion is where the selection effort sits:

• If users must combine several criteria before the list makes sense, use a list report.
• If the list is predefined and users mainly act on it, use a worklist.
• If the items are workflow tasks routed to the user by a workflow engine, My Inbox already provides the inbox, with decisions, forwarding and substitution.

Example: the purchasing team at Alder Manufacturing opens a worklist of purchase requisitions, sorted into tabs by status, and processes the open requests from Cedar Office Supply and Bright Freight one by one. A worklist is the right choice when processing, not searching, is the first step of the task.

A worklist page has four regions, top to bottom:

1. Header title: the name of the work queue, without the variant-heavy header of a list report.
2. Tabs by status: optional views, defined by developers, that split the items into groups such as open, in process and completed. Each tab can show the number of items it contains.
3. Search field: a free-text search in the table toolbar, which replaces the filter bar.
4. Table: the items themselves, with actions in the toolbar or on each row and navigation to an object page for details.

In SAP Fiori elements for OData V2, the worklist uses a responsive table by default, shows the row count in the table title and hides variant management unless the developer enables it. The V2 worklist also offers no export to spreadsheet. A worklist trades the filter bar for a flatter page that puts the items and their actions first.

The setup differs between the two SAP Fiori elements variants:

Status tabs are multiple views. Developers define them with UI.SelectionVariant or UI.SelectionPresentationVariant annotations and list them in manifest.json. In V4, multiple table mode renders an icon tab bar, and the showCounts option, off by default, adds the item count to each tab. Table columns come from UI.LineItem, and each tab can point to its own line item through a presentation variant. Configuring a worklist is therefore mostly list report configuration with the filter bar removed.

Yes. SAP documents the worklist as a simplified list report, so the list report options apply:

• Your own app: extension points add custom columns, actions and views; in OData V4, building blocks and custom pages from the flexible programming model cover larger gaps. Custom views can also be added as extra tabs through a controller extension.
• An SAP-delivered app: adaptation projects created with SAP Fiori tools, or key user adaptation, change the app without modifying SAP's code.

In SAP S/4HANA Cloud Public Edition, check which of these paths SAP supports for the app in question.

A practical limit: once users ask for several filter fields, the requirement has turned into a list report, and re-enabling the filter bar is more honest than building custom filters around a worklist. Extending a worklist works well for actions and columns, less well for search.

1. Using a worklist for open-ended search. Without a filter bar, users scroll and search instead of selecting; a list report fits better.
2. Pointing it at a huge entity set. A hidden filter bar means content loads at start, so the tabs' selection variants must already narrow the data.
3. Overlapping tabs. If one item can appear in two status tabs, counts no longer add up and users distrust the queue.
4. Expecting live counts. In OData V4, refreshing a tab's count through a global side effect works only for a view the user has already opened, so plan how counts update after actions.
5. Rebuilding My Inbox. Modeling workflow approvals as a custom worklist duplicates forwarding, substitution and task handling that My Inbox already provides.

When counts look wrong, check in order: the selection variant behind each tab, overlaps between tabs, and whether the tab was refreshed after the last action. Most worklist problems are selection-design problems, not framework defects.