Overview Page (OVP)

An overview page fits monitoring and decision-making for one area of work, such as procurement or sales, when the information comes from several entities and the user needs a quick read before acting elsewhere.

Decision criteria:

• One data set that users analyze in depth, then act on: an analytical list page.
• Several data sets that a role scans for exceptions, then drills into: an overview page.
• A personal start page across all of a user's work: My Home, the launchpad entry page in SAP S/4HANA.
• A search across many objects: a list report.

Example: the procurement lead at Alder Manufacturing opens an overview page with four cards: purchase requisitions pending approval, order value by supplier, late deliveries from Bright Freight, and quick links to the purchasing apps. Each card opens the app where the work happens. SAP's Procurement Overview Page (F1990) follows this pattern. An overview page is the right choice when a role needs breadth first and depth one click later.

An overview page has a simple structure:

1. Header: the title of the business area the page covers, with a user menu that includes managing which cards are shown.
2. Filter bar (optional): application-level filters, such as a company code or date range, that apply to every card whose entity shares the filtered property.
3. Cards in a grid: responsive columns, up to five depending on screen width, that users can rearrange by drag and drop.

Each card has two areas. The card header carries a mandatory title, an optional subtitle and a counter showing how many records the card displays out of the total for the current filter; it can also carry a KPI value with trend, which requires a service that aggregates. The content area shows a list, a table, links or a chart. Clicking a card or one of its items navigates, usually through intent-based navigation, to the app that handles the detail. The card, not the page, is the working unit of an overview page.

Every card is bound to a single entity set. UI.SelectionVariant and UI.PresentationVariant narrow and sort what a card shows, UI.Identification holds card actions, and UI.KPI configures KPI headers. Developers can also create custom cards. Overview page cards are annotation-driven components of this floorplan; UI integration cards are a separate, declarative card technology designed for reuse across hosts. Choosing card types well is most of the design work on an overview page.

All settings live in the sap.ovp section of manifest.json, at two levels:

• Page level: the model and entity set of the global filter, the container layout (a resizable layout lets users resize cards), data loading on launch, and automatic refresh, whose minimum and default interval is one minute.
• Card level: for each card, the template, the entity set, the annotation paths for line items, charts, selection, presentation and KPI, plus navigation settings.

The overview page accepts OData V2 and V4 services, even within the same page. SAP notes that its UI principles come from OData V2, that it still uses smart controls, and that only the FilterBar building block is used; the full documentation therefore sits in the V2 section of the SDK. Users can rearrange, hide, show, resize and filter cards, and moved cards keep their position. The flexible column layout does not apply to overview pages. In SAP S/4HANA Cloud Public Edition, custom overview pages depend on the extensibility options available there, so check the extensibility documentation for your release. Configuring an overview page is mostly a matter of curating cards, not building screens.

1. Cards that lead nowhere. A card without navigation shows a problem but not the way to fix it.
2. Too many cards. Twenty cards turn an overview into a scroll; keep the ones a role checks daily.
3. Ignoring authorization. Without the requireAppAuthorization card setting, users can see a card and then hit an access error when navigating. With it, the card appears only if the user may open the target intent.
4. KPI headers on non-aggregating services. KPI values need aggregation in the back end.
5. Duplicating existing apps. A card that reproduces a full list report invites users to work inside the card instead of the app.

When a card is missing or empty, check in order: whether the user hid it in Manage Cards, the requireAppAuthorization intent and the user's roles, the card's selection variant, the global filter values, then the authorization on the card's entity set. Most overview page problems come from card selection and authorization, not from the framework.