List Report

A list report fits when users start from a large, open-ended set of business objects and must narrow it down before they can work: reviewing orders due for delivery, processing a set of purchase orders, spotting documents with a payment hold, or repeating a month-end selection through a saved variant.

The decision criterion is the shape of the search. If users combine several filter criteria before the list makes sense, a list report fits. If the items are already known and few, a worklist is leaner. If users must analyze with charts before acting, the analytical list page fits better.

Example: buyers at Alder Manufacturing filter purchase orders by supplier and delivery date to find late orders from Cedar Office Supply, then open each one on its object page. A list report is the right choice when filtering is the first step of the task.

A list report page is assembled from standard parts, top to bottom:

1. Title and variant management: a views control in which users save filter values, sort order and columns.
2. Header toolbar: generic page actions, including a Share menu.
3. Filter bar: the fields in UI.SelectionFields plus every mandatory filter field. The search runs when the user chooses Go, unless live mode is configured.
4. Content area: a table, a chart, or both, optionally as several views switched by a segmented button or by tabs.
5. Navigation: choosing a row opens the object page, optionally side by side in the flexible column layout.

With a draft-enabled service, the framework adds an Editing Status filter and shows which rows have a draft or are locked by another user. Every part of a list report is generated from metadata, so list reports behave alike across apps.

In ABAP CDS the first two appear as @UI.selectionField and @UI.lineItem on each element; CAP uses the OData term names. Page behavior such as initial loading, mass edit, views and table type is set in manifest.json. Annotations decide what a list report shows; the app descriptor decides how the list report behaves.

Initial loading. When the app starts with a navigation context, such as parameters from another app or the target mapping, data loads immediately. Otherwise the user's default variant decides through its Apply Automatically setting; only the Standard variant follows manifest.json:

Users can override the setting per view. SAP recommends default filter values so the page does not open empty.

Mass edit is off until a developer enables it. In OData V4, enableMassEdit works on the list report (for active records without a pending draft) and on the object page in edit mode; visibleFields or ignoredFields limit the dialog. In OData V2, multiEdit works on the list report only, for responsive and grid tables. Both list report behaviors are deliberate configuration choices, not defaults to accept unexamined.

Yes, and the options depend on who owns the app:

• Your own app, OData V4: extension points add custom columns, actions, filter fields, header content above the filter bar and custom views as extra tabs; building blocks and custom pages from the flexible programming model cover larger gaps.
• Your own app, OData V2: extensions registered in manifest.json cover comparable areas such as columns, actions and filters.
• An SAP-delivered app: adaptation projects (SAP Fiori tools) or key user adaptation, without modifying SAP's code.

In SAP S/4HANA Cloud Public Edition, check which of these paths SAP supports for the app and release. Decision test: if custom code is needed beyond a few columns, actions or filters, revisit the floorplan choice. Extending a list report is cheap at the edges and expensive at the core.

1. Loading everything at launch. Always loading a very large entity set makes every start slow; default filter values are the better lever.
2. Opening on an empty table without explanation. When users report "no data", check in order: navigation context, the default variant and its Apply Automatically flag, the manifest setting, then mandatory filters (in OData V2, an empty mandatory filter blocks the initial load).
3. Overloading the filter bar. Twenty selection fields hide the three that matter.
4. Confusing variants and views. Variants are saved by users; multiple views are tabs defined by developers.
5. Enabling mass edit for every field. Restrict the dialog to a field group that is safe to change in bulk.
6. Using a list report for a work queue. A short, known set of tasks suits a worklist.

Most list report problems are configuration and selection-design problems rather than framework defects.