Fiori elements or freestyle: how to choose, and the concepts of the SAP front end
Fiori is design and SAPUI5 is technology. The differences between Fiori elements, freestyle and the middle ground, the Flexible Programming Model; OData, RAP and annotations; the launchpad; and how to extend a standard app without modification.
In SAP projects, "doing it in Fiori" can mean very different things: an app generated from annotations in a few hours, an app written from scratch in JavaScript over several weeks, or just an old transaction opened from a launchpad tile. Knowing the difference helps with estimating, with choosing the path and with not creating, without noticing, a modification to an SAP app.
Fiori is the design, SAPUI5 is the technology
SAP Fiori is SAP's design system: guidelines, page patterns, visual components and themes. The current theme is called Horizon. Fiori is neither a language nor a framework.
SAPUI5 is the JavaScript framework SAP uses to build Fiori apps. It ships inside SAP products: in S/4HANA, as the SAP_UI component of the front-end server, and in SAP BTP. There is also OpenUI5, the open source version (Apache 2.0 license). Both share the same core, but OpenUI5 does not include the proprietary libraries, and the whole of Fiori elements is among them.
Each S/4HANA release has its own SAPUI5 version with long-term maintenance: 1.108 in 2022, 1.120 in 2023 and 1.136 in 2025. An app has to run on the version of the customer's system, not on the newest version published on the internet.
Fiori elements: the screen that comes from annotations
With Fiori elements, the team does not write the screens. It describes what it wants to show in annotations on the OData service (which fields appear in the list, which become filters, how the detail page is divided), and the framework builds the screen when the app opens, following a floorplan, a ready-made page template:
| Floorplan | What it is for |
|---|---|
| List Report + Object Page | List with filters and a detail page: the most common case |
| Worklist | List of tasks to handle, without a filter bar |
| Analytical List Page | List with charts and analysis |
| Overview Page | Dashboard of cards with indicators and short lists |
| Form Entry Object Page | Data entry form, without the list before it |
The advantage is that the standard behavior comes ready: filters, saved variants, draft, export to spreadsheet, responsive layout and accessibility. Design improvements arrive with the SAPUI5 upgrade, with no rework in the app. Maintenance is, in SAP's words, "more on SAP side".
Fiori elements exists in two generations: the OData V2 one, still supported and present in many standard apps, and the OData V4 one, which SAP recommends for everything new.
Freestyle: everything written by the team
With freestyle, the team writes the screens (views in XML) and the logic (controllers in JavaScript or TypeScript) with SAPUI5 controls. Control is total: any layout, any data source, including outside OData. In return, every behavior that Fiori elements would provide ready-made has to be written, tested and maintained, and maintenance falls on the customer or the partner.
The middle ground: the Flexible Programming Model
Since SAPUI5 1.94, Fiori elements for OData V4 has had the Flexible Programming Model, which gives the standard app the freedoms of freestyle at the points where it needs them. There are three features:
- extension points: custom columns, actions, sections or entire pages, declared in
manifest.json; - building blocks: the pieces of Fiori elements (table, filter bar, field, form, chart) used inside a custom page, still configured by the annotations;
- controller extensions: custom code that reacts to framework events.
With a custom page, it is possible to build a page outside the floorplans using building blocks and stay within Fiori elements, with draft, filters and personalization ready. Building blocks are the successors of the old smart controls, which only work with OData V2.
How to choose
SAP sums up the recommendation in one sentence: "as much SAP Fiori elements as possible and as much freestyle SAPUI5 as needed".
| Situation | Path |
|---|---|
| The app fits a floorplan, even with small design adjustments | Fiori elements |
| It fits almost entirely, but one part needs its own layout or behavior | Fiori elements V4 with extension points or a custom page |
| Very specific process, data source outside OData, interaction no floorplan supports | Freestyle |
The most common mistake, according to SAP's own team, is discarding the floorplan too early: requirements that would fit a List Report with small concessions become freestyle, and the savings in development and maintenance are lost. The opposite also happens: forcing into Fiori elements an app that departs a lot from the standard costs more than writing it in freestyle.
Where the data comes from: OData, RAP and annotations
Fiori apps read and write data through OData services. In S/4HANA, the current path for creating these services is RAP (ABAP RESTful Application Programming Model):
- the CDS views define the data;
- the service definition states which entities the service exposes;
- the service binding publishes the service in a protocol, OData V2 or V4, for use by a UI or as an API.
The earlier paths still exist in many systems and are legacy for new development:
| Path | Status |
|---|---|
Gateway Service Builder (transaction SEGW) |
Legacy; RAP is the successor |
CDS with @OData.publish: true |
Legacy; generates OData V2 only |
| Service definition and service binding (RAP) | The recommended path; OData V2 or V4 |
The annotations Fiori elements reads can live in two places:
- in the backend, in the CDS view itself or in a metadata extension (an annotation file separate from the view). They apply to every app that uses the service;
- in the app, as a local annotation. They apply only to that app and override the backend ones, which is useful when the service is not yours.
Where the app appears: the launchpad
In S/4HANA, apps are opened from the SAP Fiori launchpad. Each app appears as a tile; tiles are grouped in catalogs, which are assigned to user roles. The current layout organizes the home screen in spaces and pages; the old home page, based on groups, is deprecated. In SAP BTP, the entry point role belongs to SAP Build Work Zone, which can bring together S/4HANA apps, custom apps and third-party apps.
The launchpad also opens SAP GUI transactions (through SAP GUI for HTML) and Web Dynpro applications, with the Fiori visual theme. They appear as tiles, but they are not Fiori apps: underneath, they are still the classic technology. SAP's Fiori Apps Reference Library shows, for each app, the technology type, the ID and everything that has to be activated to use it.
Extending a standard app without modification
An SAP Fiori app is an SAP object in the system. Changing its code directly is a modification, with the same upgrade risk as any other modification. The paths without modification are:
| Path | Who does it | What it allows |
|---|---|---|
| Key user adaptation (Adapt UI) | Key user, on the screen itself, without code | Move, hide and rename fields and sections, create variants |
| Adaptation project | Developer, in SAP Fiori tools | A variant of the app with its own ID: fields, screen fragments, extension code, local annotations, another service |
| Custom app on the same service | Developer | A new app, when the variant is not enough |
The first two use SAPUI5 flexibility, which SAP describes as "modification-free": the original app does not change, and the adjustments are applied on top of it when the screen opens. Since S/4HANA 1909, SAP has indicated the adaptation project as the way to extend its apps; the old extension project remains only for compatibility.
Even without modification, the extension has rules to survive the upgrade: use only controls with a stable ID, do not call private methods of the SAP app, and keep up with new versions of the base app. There is an ATC check (UI5_BASE_APP_VERS) that warns when the base app of an adaptation project has been updated and the variant needs to be reviewed.
Fiori and Clean Core
In the technology classification SAP publishes for Clean Core (Note 3578329), Fiori development with RAP and service binding is Level A. Services created in the Gateway Service Builder and Web Dynpro applications are Level B, and SAP Screen Personas on Web Dynpro and SAP GUI is Level D. The levels are explained in What Clean Core is, and why it became a priority.
A note of caution about the acronym: in the same note, "FPM" appears next to Web Dynpro and refers to the Floorplan Manager, a classic Web Dynpro technology. It has nothing to do with the Flexible Programming Model of Fiori elements.
A Fiori app in RAP on released CDS views is the natural path to take a classic screen out of Level B: the reason a program with a screen does not go beyond B is in Why a program with a classic screen stops at Level B, and what changes in ABAP on the server side, in ABAP Cloud: what changes compared to classic ABAP.
Common confusions
| Common idea | What holds |
|---|---|
| "Fiori is the same as UI5" | Fiori is the design; SAPUI5 is the reference technology. The Fiori theme is also applied to SAP GUI for HTML and Web Dynpro |
| "An app in the launchpad is a Fiori app" | The launchpad also opens SAP GUI transactions, Web Dynpro and links. The tile does not tell which technology it is |
| "Fiori elements cannot be customized" | There is key user adaptation, extension points, building blocks, extension code and custom pages. The real limit is departing a lot from the floorplan |
| "Freestyle is always more expensive" | Not always: when the requirement demands a lot of extension, freestyle can turn out simpler. But for a standard business app, Fiori elements costs less to build and to maintain |
| "OpenUI5 has Fiori elements" | It does not: the Fiori elements libraries exist only in SAPUI5 |
| "Smart controls work with OData V4" | No: in V4, the equivalent is building blocks |
Sources
- SAPUI5 Demo Kit (ui5.sap.com): SAPUI5 vs. OpenUI5, Developing Apps with SAP Fiori Elements, Developing Apps with Modern Concepts: Guidance for Developers, Standard Floorplans, Building Blocks, OData V4 Model, SAPUI5 Flexibility: Adapting UIs Made Easy, Extending Delivered Apps Using Adaptation Projects and Extending Apps.
- SAP, SAP Design System (SAP Fiori for Web).
- SAP Help: ABAP RESTful Application Programming Model, Service Binding, ABAP CDS – Metadata Extensions and the SAP Fiori Launchpad guide.
- SAP Fiori tools (documentation on GitHub SAP-docs/btp-fiori-tools): Capabilities Overview, Supported Floorplans, Upgrade Safe Compatibility Rules and Check Whether Your Adaptation Project Is Up-To-Date with Base App Upgrades.
- Stefanie Hager (SAP), Leverage the flexible programming model to extend your SAP Fiori elements apps for OData V4, SAP Community, 2021.
- Peter Spielvogel (SAP), How to create an SAP Fiori app using SAP Fiori elements, SAPUI5 freestyle, or a mix of both, SAP Community, 2022.
- SAP Fiori Apps Reference Library, extensibility section of the app fact sheets.
- SAP Note 3578329 (technology classification for Clean Core).