Form Entry Object Page

A form entry object page fits when the whole task is entering data for one new object and users have nothing to search for first: a request form, a registration, a simple purchase requisition raised from a tile.

Decision criteria:

• No list needed and no context to review before typing: a form entry object page.
• The object needs a status, key facts or related items in view: a standard object page.
• Users search, then create or edit one of many objects: a list report with an object page.
• Only two or three fields: dialog-based creation from a list report is lighter.

Example: an employee at Alder Manufacturing opens a "Create Purchase Requisition" tile, lands directly in an empty form, enters twelve office chairs from Cedar Office Supply and chooses Create. A form entry object page is the right choice when the app is the form.

A form entry object page has three regions:

1. Page title: identifies what is being created, such as a new purchase requisition.
2. Form sections: the sections and field groups defined in UI.Facets, stacked on one page.
3. Footer bar: the actions that save or discard the new object, plus access to validation messages.

What is missing is deliberate: no header facets with key facts, no image, no anchor or tab bar between sections. Because the page shows the same content as a standard object page, a section that works on one also works on the other. A form entry object page is an object page reduced to the form and the decision to save it.

In SAP Fiori elements for OData V4, three settings turn an object page into a form entry page:

1. Target settings in manifest.json: the target uses the object page template, with content.header.visible and content.header.anchorBarVisible set to false and the header content not editable.
2. Create mode at start: the app component returns a preferred mode of create from its startup parameters, so the app opens an empty object instead of waiting for a selection.
3. One draft at a time (optional): the app-level setting singleDraftForCreate makes the app reopen the user's unsaved draft instead of creating another one.

The annotations do not change: UI.Facets, UI.FieldGroup and UI.Identification define the form exactly as for a standard object page. SAP documents the pattern for SAP Fiori elements for OData V4 only. It is a property of the app, not of the system, so it works the same in SAP S/4HANA and on SAP BTP wherever a SAPUI5 release that supports these settings runs; check the SAPUI5 SDK for your version. Configuring a form entry object page is therefore a page-setting decision, not a modeling task.

1. Forgetting the start mode. Without the create preference, the app does not open in creation mode, and users have no obvious way to begin.
2. Collecting drafts. Every abandoned start can leave a draft; singleDraftForCreate reopens the existing draft instead.
3. Long forms without navigation. With the anchor bar hidden, a ten-section form becomes a long scroll; split the object or use a standard object page with tabs.
4. Editing existing objects in a form entry page. Without a header, users lose the status and key facts they need when changing data.

When the app opens in display mode or empty instead of create mode, check the startup parameters in Component.js, then that the first target is the object page template, then the draft settings of the service. Most form entry object page problems are start-up configuration problems, not annotation problems.