Fiori Elements List Report and Object Page
List Report and Object Page are the two standard Fiori elements floorplans used together to build a search-and-detail application: a filterable table of results (List Report) that navigates into a structured detail screen with sections, tables and facets (Object Page). Both are generated at runtime from CDS annotations and an OData service metadata document, not from hand-written UI5 views.
Covers the List Report plus Object Page floorplan pairing that underlies most transactional Fiori apps built on RAP and CDS. Focuses on how annotation-driven rendering actually breaks in projects, when to trust the generated UI versus when to reach for freestyle, and what a clean handover between developer and functional consultant looks like.
Published 16 Sept 2026· 1,372 words
What it is
List Report and Object Page are two floorplans in the Fiori elements framework. List Report renders a filter bar and a results table against an OData entity set. Selecting a row navigates to the Object Page, which renders header facets, sections, tables and forms for that entity and its associations. Neither screen has a hand-written view or controller; both are generated at runtime by the UI5 framework reading the OData service's metadata document together with a layer of UI annotations attached to the underlying CDS view. The one fact that explains most confusion: the UI you see is not configured in the frontend at all. It is a rendering of annotations that live in the backend CDS layer, or in a metadata extension, or in a manifest.json fragment, and figuring out which of those three owns a given piece of UI behaviour is the actual skill, not writing UI5 code.
When to use it
Use this pairing for standard transactional or master data apps: display, create, edit, approve, a table of line items with a header. Most RAP-based CRUD apps fit this shape and get a working app with almost no frontend code. It stops being the right tool when the required interaction cannot be expressed as filter-table-navigate-detail: multi-object canvases, drag-and-drop scheduling, custom visualisations, wizard-style multi-step flows, or a layout where two unrelated business objects must be edited side by side. Also reconsider it when the object page would end up with a dozen forced tabs just to shoehorn an unrelated process into one screen, or when the business asked for a specific pixel layout that annotations cannot express. In those cases freestyle SAPUI5, or a flexible programming model app embedding a Fiori elements section as one building block, is the better fit.
How it fits the stack
Below the floorplan sits the OData service, typically V4 generated from a service definition and service binding over a RAP business object, itself built on CDS view entities with behaviour definitions. Above the floorplan sits the Fiori launchpad, which hosts the app tile and routes to it via the app's manifest. The floorplan replaces what used to be a hand-coded SAPUI5 master-detail app or a Web Dynpro ABAP transaction: the developer effort moves from writing views and controllers to writing annotations and, where behaviour is non-standard, targeted controller extensions or a flexible programming model extension. Draft handling, if the business object supports it, is rendered automatically as the draft indicator and save/activate buttons on the Object Page toolbar without any explicit UI code for that logic.
A worked example
A sales order item approval app: List Report shows open items with filters on plant, approval status and requested date, backed by a CDS projection view exposing a RAP-managed business object. UI.lineItem and UI.selectionField annotations on the projection determine which fields appear in the table and filter bar. Navigating into a row opens the Object Page, where UI.facet annotations define a general information section, a header identification area, and a table facet showing the order's line items exposed through a to-many association in the CDS view. An action defined in the behaviour definition, 'Approve', is exposed as a button on the Object Page toolbar via a UI.identification or UI.lineItem annotation depending on placement, and its enablement is controlled by the operations control on the entity, not by frontend logic. No JavaScript controller code is written; the entire app is delivered as annotations plus the generated service binding.
How to choose
- List Report plus Object Page versus freestyle: choose freestyle only when the interaction genuinely cannot be described as filter, table, navigate, detail sections. Freestyle costs ongoing UI5 maintenance and loses automatic draft handling, automatic personalization and automatic accessibility compliance that Fiori elements gives for free.
- Single Object Page versus multiple sub-object pages: if a business object has several independently maintained child entities with their own lifecycle, consider separate object pages linked by navigation rather than forcing everything into one page's facets, which becomes unmanageable to test and slow to render.
- Where does an annotation belong: CDS view itself for annotations everyone should always see, a metadata extension for UI-only annotations kept separate from the data model so functional teams can adjust layout without touching the view, or the app's manifest for app-specific overrides. Mixing all three for the same field is the single most common source of unexplainable rendering.
- Standard action button versus custom fragment: before writing a controller extension to add a button, check whether the same result is achievable with a RAP action exposed through annotations. Custom fragments survive upgrades worse and require frontend developer time on every future change.
- Table type on the Object Page: responsive table versus grid table versus analytical table changes performance characteristics under volume; decide based on expected row count and required column count before annotating, not after users complain.
Common pitfalls
- A field visible and correctly labelled in the CDS view but missing from the rendered table or facet almost always means an annotation exists in a metadata extension or manifest that is silently overriding or hiding it; searching only the CDS view wastes time.
- List Report performance is fine in the test system with fifty rows and unacceptable in production with fifty thousand, because the default table type and default page size were never revisited; this is invisible until real volume hits.
- Draft-enabled Object Pages that were tested only by a single developer often hide locking and stale-draft cleanup problems that surface only when multiple users edit the same object concurrently in production.
- Adding a controller extension to fix a rendering quirk works in the IDE and then breaks silently after a UI5 or Fiori elements version upgrade because the extension relied on an internal control structure that was never a stable extension point.
- Facets and sections defined with hardcoded field lists become invisible maintenance debt: a field added to the CDS view later does not automatically appear anywhere, and nobody remembers which annotation file to edit.
- Value help and filter bar defaults configured only in the manifest, rather than as CDS annotations, do not travel with the service when it is reused in another app, causing the second app to look inconsistent with the first for no visible reason.
ECC, S/4HANA and clean core
This is the standard, currently promoted UI approach for transactional apps built on RAP in S/4HANA, and it is the direction clean core points toward: annotation-driven UI on top of a released, extensible CDS and OData layer rather than a bespoke UI5 app hand-coded against custom tables. Freestyle SAPUI5 is not deprecated but is now the exception rather than the default for new transactional development. Older classic SAPUI5 master-detail apps and Web Dynpro ABAP transactions are the pattern this replaces, and migrating them is usually done by rebuilding the RAP business object and re-annotating rather than porting the old UI code.
Whose problem this is
Primarily a developer and UX or Fiori consultant responsibility, working from a functional specification of fields, filters, facets and actions. Handover from functional to developer should list which fields are filterable, sortable, mandatory, and which actions and their enablement rules exist on the underlying business object, since that determines annotation placement rather than frontend code.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/fiori-elements-list-report-and-object-pageERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.