What the Object Page Is
The object page is the detail view of a Fiori Elements app. Click a row in the list report and you land here: a header with the key facts, then sections that break the object into logical chunks. Every piece of it is annotation-driven, just like the list report.
Say you have a sales order. The header shows the order ID, customer, and status. Below it you get sections: general details, line items, notes, attachments. Each of those is a section, and the annotation model decides which exists and in what order.
Sections: The Building Blocks
A section is one collapsible block on the object page. The UI.Facets annotation defines them. Each facet becomes a section, and the facet's target decides what the section contains.
@UI.facet: [
{ id: 'General',
purpose: #STANDARD,
type: #FIELDGROUP_REFERENCE,
label: 'General Information',
targetQualifier: 'General' },
{ id: 'Items',
purpose: #STANDARD,
type: #LINEITEM_REFERENCE,
label: 'Items',
targetElement: '_Items' }
]A FIELDGROUP_REFERENCE facet shows a form of fields. A LINEITEM_REFERENCE facet shows a table of a child entity — the classic items table under an order header. The id must be unique; the label is what the user reads.
Key takeaway: facets are the table of contents of the object page. If a block of information should be visible at a glance, it deserves its own facet.
Subsections: Grouping Inside a Section
When a section gets crowded, split it with subsections. A facet with type: #COLLECTION becomes a parent, and the facets nested under it render as subsections inside it.
This is how you keep a long object page scannable. Say the general section carries addresses, payment terms, and delivery info — three subsections under one collection facet read far better than thirty fields in a flat list.
Subsections can also be tabbed. Setting the facet's presentation appropriately lets related subsections appear as tabs, which works well when each subsection is dense but the user only needs one at a time.
Field Groups: What's Inside a Form Section
A form section does not list fields directly. It references a field group, defined with UI.FieldGroup, and the field group lists the fields with their positions.
@UI.fieldGroup: [ { qualifier: 'General',
position: 10 } ]
SalesOrderID;
@UI.fieldGroup: [ { qualifier: 'General',
position: 20 } ]
CustomerName;The qualifier ties the field group to the facet's targetQualifier. If a field does not show up in the section, the qualifier mismatch between the facet and the field group is the first thing to check.
Tables Inside Sections
Child entities render as tables when the facet uses LINEITEM_REFERENCE with a targetElement pointing at the association. The table's columns come from the child entity's own UI.LineItem annotation — the same one its list report would use.
This reuse is deliberate. Annotate the child entity once, and both the standalone list report and the embedded table on the parent's object page stay consistent. One annotation, two consumers.
Resist the urge to create a section for every field. A good object page has five to eight sections; beyond that, users stop scrolling. Group ruthlessly.
Ordering and Hiding
Facet order is the section order. Put the most-used section first — usually the items table or the key details — not the administrative fields. Users should not scroll past creation metadata to reach the content they came for.
You can hide sections conditionally with the usual annotation mechanisms, and personalization lets users collapse what they do not need. Design for the common case, then let the edges be configurable.
How many sections do your object pages usually end up with — and do you group them into tabs? Let me know in the comments.