Object Page

An object page fits whenever the task centers on one business object: changing a sales order and its items, creating a purchase order as a draft, releasing a blocked invoice, or comparing a draft with the saved version. The floorplan scales from a few fields to complex objects with many sections and related tables.

Two decision criteria help:

• If users need context first, such as the object's status, key figures and related items, the standard object page fits.
• If users only enter data and need no header or section navigation, the form entry object page, a variation that hides both, is leaner.

Example: an Alder Manufacturing buyer opens a purchase order for Bright Freight, checks the header facts, then edits two items. An object page fits when the question is "what about this one object?"

An object page is built from five areas, top to bottom:

1. Header title: the object's title and subtitle, an optional image, the editing status when a draft exists, and a toolbar with actions such as Edit, Delete, Related Apps and Share.
2. Header facets: key facts as label-value pairs or small visuals such as a micro chart or rating. SAP recommends at most five label-value pairs.
3. Navigation bar: anchors that jump to each section on one scrolling page, or tabs that show one section at a time.
4. Content area: sections and subsections holding forms, tables of related items, charts or reuse components.
5. Footer toolbar: in edit mode, Save or Create, determining actions and the message button.

Choosing a row in an item table opens a subobject page for the child entity, with paging buttons to move between items. Each area of an object page answers one question: what is this, what matters, where is it, how do I finish.

In ABAP CDS all of these facets are written as @UI.facet entries with a type, such as a field group reference or a collection, and a purpose that separates header facets from standard sections. Only two levels of collection facets are rendered. The choice between anchors and tabs is a manifest.json setting, sectionLayout, with Page as the default in OData V4. The object page's structure is therefore defined almost entirely in UI.Facets.

With a draft-enabled service, the object page creates a draft as soon as a user starts editing or creating. The draft is saved in the background while the user works, which gives four behaviors:

• unsaved work survives an interruption or a crash, and the user can resume later;
• the draft acts as a lock, so other users see that the object is being edited;
• validations and field control run during editing, not only at the end;
• Save turns the draft into the active version.

SAP Fiori elements for OData V4 distinguishes exclusive drafts, owned by one user, from collaborative drafts that several users can edit together; SAP documents collaborative drafts only for RAP-based services. RAP and CAP both provide draft handling on the service side. Without draft, nothing reaches the back end until the user saves, and SAP advises non-draft apps only for simple flows. Draft support is the service decision that most shapes how editing feels on an object page.

Yes. The options depend on who owns the app:

• Your own app: extension points add custom sections and subsections, header facets, form elements, actions and table columns; reuse components can be placed in sections; with OData V4, building blocks and custom pages from the flexible programming model cover larger gaps.
• 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, the available paths follow SAP's extensibility models there; check the extensibility documentation for your release.

Custom sections carry a performance cost. OData V4 offers request groups and lazy loading for object pages; in OData V2, lazy loading must be switched on for each custom section. A practical test: if most sections are custom, a custom page or freestyle SAPUI5 may be more honest than a heavily extended object page.

1. Too many sections on one scrolling page. Group sections or switch to tabs, which SAP recommends for grid tables.
2. Overloaded headers. More than a handful of header facts turns the header into a second form.
3. Deep facet nesting. Collection facets below the second level are ignored, and a collection facet wrapping a single reference facet can render badly; use the reference facet directly.
4. Commas in section titles. SAP Fiori elements uses commas as delimiters when grouping messages, so avoid them in section and subsection titles.
5. Editing without draft. Users lose resume and lock information.

When a section is missing, check in order: the UI.Facets annotation in the service metadata, the facet's level, its target qualifier, any UI.Hidden condition, and a local annotation file that may replace the back-end UI.Facets. Most object page defects are facet-structure problems, not rendering bugs.