SAP Fiori & UX Development
SAP Fiori is SAP's design system and UX platform — replacing the transaction-driven SAP GUI with role-based, mobile-responsive web applications that users actually want to use. A well-designed SAP Fiori experience drives adoption, reduces training time and keeps users in the system rather than working around it in spreadsheets. 2iSolutions designs and develops SAP Fiori applications across the full spectrum — from standard Fiori app activation and launchpad configuration through custom SAPUI5 development, Fiori Elements and BTP-hosted portals for external users.
SAP GUI vs SAP Fiori — what the shift actually changes for users
Fiori is not a cosmetic update to SAP GUI. It is a fundamentally different UX paradigm — role-based instead of transaction-based, browser-native instead of client-installed, and designed around the task a user needs to complete rather than the system structure beneath it.
The system you navigate
- — User must know transaction codes to access functions
- — Dense, form-heavy screens designed for power users
- — Desktop client required — not browser or mobile
- — No responsive design — unusable on tablet or phone
- — Long training time — steep learning curve
- — Users work around the system in spreadsheets
- — Identical UI for all roles — no personalisation
The experience designed for the user
- ✓ Launchpad shows only apps relevant to the user's role
- ✓ Task-focused apps — one screen, one clear purpose
- ✓ Runs in any browser — no client installation
- ✓ Fully responsive — same app on desktop, tablet, phone
- ✓ Intuitive enough for occasional users — low training
- ✓ Live S/4HANA data — eliminates offline workarounds
- ✓ Role-specific — finance, warehouse, field service each differ
SAP ships 2,000+ standard Fiori apps — activating the right ones for each role is the starting point. When gaps exist, custom SAPUI5 apps fill them. The Fiori Launchpad becomes the single point of access for all SAP functionality, replacing the transaction code paradigm entirely.
SAP Fiori & UX services — from design to deployment
Fiori Launchpad Configuration
Designing and configuring the SAP Fiori Launchpad — the role-based home screen where users access all Fiori apps. Catalogue and group structure mapped to job roles, tile configuration, app finder and search, theming with corporate branding and role-based visibility ensuring each user sees only what is relevant to their job function.
Custom SAPUI5 App Development
Building bespoke Fiori applications using SAPUI5 — SAP's enterprise JavaScript UI framework. Custom apps follow SAP Fiori design guidelines so they are visually consistent with standard SAP apps. For processes SAP doesn't cover with standard apps — approval workflows, custom dashboards, shop floor apps, portal screens — SAPUI5 is the right tool.
Fiori Elements Development
Accelerated Fiori app development using SAP Fiori Elements — where the UI is generated from OData service annotations rather than hand-coded. List Report, Object Page, Overview Page and Worklist templates cover most transactional scenarios. Faster to build, lower maintenance and automatically consistent with Fiori design updates delivered by SAP.
OData Service Development (RAP)
Every Fiori app needs an OData service for S/4HANA data. We build OData services using SAP's RESTful Application Programming Model (RAP) — CDS views for data modelling, behaviour definitions for business logic. RAP is SAP's current standard for S/4HANA backend development and the prerequisite for Fiori Elements apps.
BTP-Hosted Fiori Apps & Portals
Fiori apps deployed on SAP BTP for external users — dealers, suppliers, customers — who need access to S/4HANA data without direct system access. HTML5 Application Repository for hosting, Destination Service for connectivity, XSUAA for authentication. Preferred for customer-facing portals, dealer order portals and supplier self-service screens.
Standard Fiori App Extension
Adapting standard SAP Fiori apps without core modification — using SAP UI Adaptation, Flexibility Layer and SAPUI5 extension points. Adding fields, changing layouts, injecting custom actions into standard apps in an upgrade-safe way that survives SAP support packages and quarterly updates.
SAP Fiori design system — the framework every app is built on
SAP Fiori is not just a component library — it is a comprehensive design system with defined principles, patterns, interactions and guidelines. Every app built on this system is automatically consistent with every other Fiori app, reducing the cognitive load for users who work across multiple applications.
Why the design system matters for custom apps: Custom SAPUI5 apps built to Fiori design guidelines look and behave identically to standard SAP apps. Users who know how to use My Purchase Orders know how to use a custom approval app built on the same system — zero additional training.
The Fiori apps we build — by role and use case
Custom Fiori app requirements group into recognisable patterns by business role. Each card below represents a category of app we regularly design and build — not hypothetical templates, but live production apps running in client S/4HANA and BTP landscapes.
Custom Approval Dashboards
Multi-level PO, bill and capex approval apps with conditional routing beyond SAP standard — threshold-based chains, delegation, escalation and mobile-first approval actions.
Executive KPI Dashboards
Real-time operational dashboards for C-suite and department heads — production status, financial KPIs, procurement pipeline, inventory aging — aggregating S/4HANA data in one view.
Shop Floor & Warehouse Apps
Tablet-optimised apps for warehouse and production staff — work order queues, time confirmation, barcode scanning, goods receipt and transfer orders without SAP GUI navigation.
Supplier Self-Service Portals
BTP-hosted Fiori portals for suppliers — PO acknowledgement, delivery confirmation, document upload, GRN status and account statement access without exposing S/4HANA directly.
Customer Portals
Customer self-service on SAP BTP — order status, delivery tracking, invoice download, credit note request — built on S/4HANA data via APIs, not a separately maintained web application.
Dealer & Channel Apps
DealerConnect — 2iSolutions' own Fiori app on SAP BTP — lets dealers place orders, view scheme availability, track secondary sales and check outstanding statements in real time.
Mobile Field Sales Apps
Mobile Fiori apps for field representatives — customer visit logging, order capture at agreed pricing, service confirmation, offline capability with sync on reconnect via BTP.
Employee Self-Service Apps
Custom ESS apps beyond SAP standard — leave request with custom approval logic, travel request, shift swap, custom timesheet entry for non-standard work patterns.
Industry-Specific Custom Apps
Deckle plan visualisation for paper manufacturers, batch record apps for pharma, production schedule apps for discrete manufacturing — Fiori built on industry process knowledge.
Five-phase Fiori & UX development process
A Fiori app that is technically correct but designed for the developer rather than the user will not be adopted. Our process starts with the user — understanding who will use the app, in what context and with what constraints — before a single line of code is written.
Discover
User research, role mapping, workflow observation, pain point identification — who uses this, how and why
Design
Wireframes, Fiori pattern selection, interaction design, prototype review with business users before development
Build
SAPUI5 / Fiori Elements frontend, RAP OData backend, BTP deployment pipeline — frontend and backend by same team
Test
UAT with actual end users, device testing (desktop, tablet, mobile), accessibility validation, performance benchmarking
Deploy & Sustain
Launchpad deployment, user training, hypercare and ongoing support under AMS — apps maintained as system evolves
What good Fiori UX looks like
- Users complete tasks in under 3 taps or clicks
- App purpose is clear from the home tile alone
- Works on the device users actually carry
- Data visible without needing to search for it
- Errors explained in business language, not codes
- Same visual language as every other Fiori app
- Adopted without requiring users to be trained twice
How we know it's working
- Users complete tasks using the app, not by calling IT
- Error rate on key transactions drops post-launch
- Adoption rate measured at 30, 60 and 90 days
- No reversion to SAP GUI for covered functions
- App load time under 2 seconds on target devices
- Support ticket volume for covered processes decreases
- Users request more apps — not fewer
What makes our Fiori & UX development practice different
Full-Stack — Frontend & Backend Together
SAPUI5 frontend developers and ABAP RAP backend developers in the same team — the OData service and the Fiori app are designed together, not handed off between separate teams with a contract in the middle. Integration issues surface during development, not UAT. Backend performance problems are caught when the OData service is built, not when users report slow load times three months after go-live.
Four Proprietary BTP Apps in Production
DealerConnect, ShopConnect, SupplierConnect and ServiceConnect — 2iSolutions' own Fiori applications — are deployed in live client operations using the same SAPUI5, OData and BTP architecture as custom Fiori development. We write the same code for clients as we wrote for our own products. This is product-grade delivery, not prototype delivery.
Upgrade-Safe by Design
Standard apps extended using SAP's Flexibility Layer and UI Adaptation — not core modifications. Custom apps built on OData v4 and RAP to avoid Gateway technical debt. Every app designed to survive SAP quarterly updates (Public Edition) and support packages (Private Edition). We don't build Fiori apps that break every time SAP releases an update.
Fiori for External Users — BTP Deployment
Dealer portals, supplier self-service, customer-facing apps — these require BTP deployment (HTML5 Application Repository, Destination Service, XSUAA), not embedding in S/4HANA. We deploy Fiori on BTP and manage the BTP landscape as well as the app — one team for the full stack, not separate BTP and Fiori partners.
Functional Knowledge Behind the UI
A Fiori app that exposes the wrong process or the wrong data is unusable regardless of how well it's designed. Our developers work with functional consultants who understand what the Finance, Procurement, Manufacturing or Sales user actually needs — so app requirements are functionally correct before development begins, not corrected in UAT after the app is built.
Apps Maintained Under AMS
Custom Fiori apps need ongoing maintenance — SAP updates affect standard app extensions, OData services need updating when S/4HANA data models change, new requirements emerge as users adopt the apps. We maintain custom Fiori applications under the same AMS contract as the S/4HANA system — one team, one contract, continuous improvement.
Fiori & UX development from a Gold Partner that built four production apps on SAP BTP
DealerConnect, ShopConnect, SupplierConnect and ServiceConnect are live in client operations — not portfolio pieces. The same SAPUI5, OData and BTP capability is available for every custom Fiori engagement.
SAP Fiori & UX development: frequently asked questions
What is the difference between SAP Fiori, SAPUI5 and SAP GUI?
SAP GUI is SAP's traditional desktop client — transaction-based, not responsive, not browser-native. SAPUI5 is SAP's JavaScript UI framework — the technology on which all Fiori apps are built. SAP Fiori is the design system and UX platform — the guidelines, patterns and standard apps built on SAPUI5. When we say "custom Fiori app," we mean a custom SAPUI5 application following Fiori design guidelines, running in the Fiori Launchpad or on SAP BTP.
Should we use standard Fiori apps or build custom ones?
Standard first, custom where gaps exist. SAP ships 2,000+ standard Fiori apps for S/4HANA — covering most standard ERP processes. The right starting point is a Fiori readiness assessment: which standard apps are fit for your processes, which need configuration or extension, and where genuine gaps require custom SAPUI5 development. Building custom apps for processes SAP standard already covers wastes investment; not building them where real gaps exist means users revert to SAP GUI or offline tools.
What is Fiori Elements and how does it differ from custom SAPUI5?
Fiori Elements generates the UI automatically from OData service annotations — you define the data model and annotate it, and Fiori Elements builds the List Report, Object Page or Worklist screen without manual UI coding. It's faster, lower-maintenance and automatically consistent with SAP's design updates. Custom SAPUI5 is hand-coded JavaScript when the required UI doesn't fit Fiori Elements patterns — complex visualisations, highly interactive screens, or apps with non-standard navigation. Most new transactional apps start with Fiori Elements; only those with genuine custom interaction requirements need full SAPUI5.
Can Fiori apps work on mobile phones and tablets?
Yes — responsiveness is a core Fiori design principle. All Fiori apps are built with SAPUI5's responsive grid layout, adapting automatically to desktop, tablet and phone screen sizes. Some apps are specifically designed for tablet or mobile-first use — warehouse scanning apps on handheld devices, field sales apps on smartphones, shop floor dashboards on wall-mounted tablets. Device testing on the actual target hardware is part of our UAT process, not an assumption.
What is the RAP framework and why is it important for Fiori?
RAP (RESTful ABAP Programming Model) is SAP's recommended backend framework for building OData services that power Fiori apps on S/4HANA. CDS views define the data model; behaviour definitions add the business logic; ABAP classes implement it. RAP is the replacement for older SAP Gateway development and generates OData v4 services consumed by Fiori Elements apps. Apps built on RAP are more consistent, better performing and more upgrade-safe than those built on the older Gateway approach. We use RAP for all new S/4HANA Fiori backend development.
How long does a custom Fiori app take to build?
A focused single-purpose Fiori app — a custom approval workflow, an operational dashboard, a supplier confirmation screen — typically takes 6–10 weeks from requirements to Fiori Launchpad deployment. More complex apps with multiple user roles, offline capability, BTP deployment and significant RAP backend development take 10–20 weeks. The timeline is driven by the OData service complexity, the number of UI screens, integration requirements and the testing scope. We provide a fixed-scope estimate after the discovery and design phase, before development begins.
Want to know which standard Fiori apps are ready to activate — and where custom development adds value?
A Fiori readiness assessment maps your user roles against SAP's standard app catalogue, identifies fit and gaps, and recommends the right mix of activation, extension and custom development — before any development budget is committed.