Fiori Elements vs Freestyle: Picking the Right Tool
Lesson 3 — Once your OData is V4, the next real decision is what to build the UI in. Most teams pick by habit, not by heuristic. Here's how Fiori Elements actually works, the five official floorplans, and the one real, official link to Clean Core that isn't marketing.
Prerequisites
- Lesson 2: OData V2 to V4 — what actually changes
Once your OData is V4, the next real decision isn’t technical plumbing — it’s what to build the UI in. Most teams pick freestyle SAPUI5 by habit, because that’s what the last developer on the project knew. That’s not a heuristic. Here’s an actual one.
What Fiori Elements actually is
Fiori Elements is metadata-driven: it consumes OData V4 service metadata plus vocabulary-based UI annotations — @UI.lineItem, @UI.identification, @UI.headerInfo, @UI.selectionField, and others from the com.sap.vocabularies.UI.v1 vocabulary — commonly authored as CDS annotations on the ABAP side. The floorplan reads those annotations and generates the UI at runtime. There’s no hand-written view or controller for the standard case.
Five official floorplans cover almost every transactional and reporting scenario:
The real, official Clean Core link
This isn’t an inference — SAP’s own Clean Core course states it directly: “SAP Fiori is also an important part of the clean core approach,” because Fiori apps consume S/4HANA Cloud data through well-defined, upgrade-stable remote APIs rather than touching the core. An app built on a standard floorplan gets layout, accessibility, and theme updates automatically when SAP ships a new UI5 version — you own no layout code, so there’s nothing of yours to break on the next upgrade.
When freestyle is still the right call
SAP’s own Fiori Elements FAQ is honest about the boundary: when “the building blocks do not meet your needs and/or you require heavy modification to the standard floorplans, it may be better to create a custom application.” That cuts both ways — forcing a genuinely custom, non-standard interaction into a floorplan it wasn’t designed for erodes the exact maintenance benefit you were trying to get. Complex multi-step wizards with conditional navigation, non-standard visualisations beyond @UI.chart, and apps embedding third-party components are the legitimate freestyle cases.
Try it yourself
Take one app — real or hypothetical — and classify it: does it fit List Report + Object Page, Worklist, Overview Page, or Analytical List Page? Or does it genuinely need freestyle? Write one sentence justifying the choice using the heuristic above, not habit.
Go deeper
For the complete floorplan reference and the maintenance-benefit argument in full, read SAP’s official Fiori Elements FAQ. For the exact Clean Core language quoted above, see SAP Learning’s Clean Core extensibility course.
Key takeaways
- Fiori Elements is metadata-driven — OData V4 + UI vocabulary annotations generate the UI; there’s no hand-written view for the standard case.
- Five floorplans — List Report, Object Page, Overview Page, Worklist, Analytical List Page — cover most transactional and reporting needs.
- The Clean Core link is real, not inferred — SAP explicitly frames Fiori as part of the clean-core approach because it consumes data through upgrade-stable APIs.
- Freestyle is still correct when the floorplans genuinely don’t fit — not when a developer just prefers writing controllers.
Next: how do you actually read a UI5/Fiori readiness check, the same way you’d read an ABAP one?