The Fiori launchpad is where every S/4HANA user starts their day, which makes it the most visible thing a Basis team administers: when it is slow, everything is slow, and when a tile is missing, that's a ticket within the hour. It is also — behind the clean grid of tiles — a stack of roles, catalogs, caches, and OData services with more moving parts than its surface suggests.
This is the launchpad from the administrator's side: how the content model actually works, what the initial setup involves, and the diagnostic order for the two tickets you will see over and over.
What the launchpad is
The SAP Fiori launchpad (FLP) is the role-based entry point for Fiori applications: a browser-based shell that shows each user a personalized set of app tiles, plus search, navigation, and notifications. On an ABAP frontend server it lives at the /ui2/flp path and can be opened from the GUI with transaction /UI2/FLP.
The word *role-based* is doing all the work in that definition. The launchpad has no content of its own — everything a user sees and can launch is derived from their PFCG roles. Administering FLP is therefore mostly administering role content, which is why it lands with Basis and security teams rather than developers.
Where it runs. For S/4HANA, SAP recommends the embedded deployment: the Fiori frontend server components run inside the S/4HANA system itself rather than on a separate central hub system. Standalone hubs still exist in older landscapes, and central entry points have largely moved to the cloud (SAP Build Work Zone on BTP — the successor of the BTP Launchpad service) for organizations that want one launchpad across many systems. If you're building fresh on S/4HANA, embedded is the default assumption.
The content model: two layers, endlessly confused
Nearly every launchpad content question reduces to two layers:
| Layer | Object | Answers the question |
|---|---|---|
| Authorization | Catalog (tiles + target mappings) | What is this user *allowed to launch*? |
| Layout | Group (classic) / Space and pages (current) | What does this user *see on the home screen*? |
A catalog contains tiles and their target mappings — the piece that connects a tile to the actual app, transaction, or URL it launches. Catalogs are assigned to users through PFCG roles. A user can launch anything in their catalogs (search will find it) even if no tile is placed on their screen.
A group is the classic home-screen layout unit. Recent S/4HANA releases replace groups with spaces and pages — a two-level layout (a space contains pages, pages contain sections of tiles) that scales much better for large role sets, and which SAP has made the default direction. Migrating from groups to spaces is a project worth doing deliberately, not a checkbox.
The recurring confusion: a tile placed in a group without the backing catalog assignment produces a tile that *renders but won't launch*; a catalog assignment without tile placement produces an app that *works but is invisible* until searched for. Half of all "Fiori is broken for this user" tickets are one of these two states.
Tools: the classic Launchpad Designer (/UI2/FLPD_CUST) edits catalogs and groups; the Launchpad Content Manager (/UI2/FLPCM_CUST) is the newer tool for managing catalogs and analyzing content at scale, and the spaces/pages model has its own editors. The Fiori apps reference library (SAP's online catalog of every delivered app, its prerequisites, and its activation details) is the other tab you will always have open.
Initial activation: what the Basis work actually is
Standing up the launchpad on a fresh system is well-trodden Basis work:
- Run the delivered task lists. SAP ships task lists (run via transaction STC01) that automate the foundational setup — activating the launchpad's ICF services, setting up the embedded gateway, and preparing the UI infrastructure. Use them; clicking through it manually reproduces the task list badly.
- Activate the OData services for the apps you deploy, via
/IWFND/MAINT_SERVICE. Every Fiori app rides on one or more OData services, and an inactive service is the classic cause of a tile that renders and then errors on launch. - Activate the SICF nodes the apps need — delivered inactive by default as a security posture.
- Build the role content — catalogs, then layout, then PFCG roles tying them to users, ideally copied from SAP's delivered business roles and trimmed rather than built from nothing.
- Transport it. Catalogs, groups, spaces, and pages are transportable objects. They should travel through the landscape like any other change; landscapes where launchpad content is hand-maintained per system drift immediately and forever.
The cache chain, or: "I changed it and nothing happened"
The launchpad is aggressively cached at several layers — server-side UI2 caches, the browser, and any CDN or reverse proxy in front. This is essential for performance and maddening for administrators, because a content change that doesn't appear is almost never broken and almost always cached.
The habit to build: after content or configuration changes, invalidate deliberately rather than waiting hopefully. The frontend server provides cache invalidation reports — `/UI2/INVALIDATE_GLOBAL_CACHES` is the blunt instrument that clears the UI2 caches globally, with more targeted variants available — and the user-side test is always a hard reload or private browser window to take the browser cache out of the equation. If a change appears in a private window but not a normal one, the server is fine and the browser cache is your whole problem.
Diagnose in this order: private window first (browser cache), then server cache invalidation, then — only if both fail — question the change itself.
When a tile launches into an error
The second recurring ticket: the tile is present, the user clicks, and an error appears. This is almost always the OData layer, and the gateway keeps receipts: `/IWFND/ERROR_LOG` on the frontend server shows the failing service call, the HTTP status, and usually a painfully specific error text. Work from there rather than from the browser's screenshot.
The usual suspects, in frequency order: OData service not activated in this system (a transport landed but the service activation is system-local), missing start authorization for the service (S_SERVICE) in the user's roles, and — in hub deployments — a broken trust or RFC connection between frontend and backend. The error log distinguishes these in seconds.
Performance: the launchpad is a first impression
FLP performance is dominated by the initial load, and the levers are unglamorous but effective: keep role content lean (a user with forty catalogs pays for forty catalogs at every logon), stay current on SAPUI5 patch levels, let the cache infrastructure do its job rather than fighting it, and measure from the user's network position, not from the data center. A launchpad that loads in two seconds on the LAN and twelve over VPN is a network conversation, not a Basis one — but you want the measurements before that meeting.
Launchpad administration — role content, activation, caches, gateway errors, performance — is a standing part of our managed Basis services, and the "our Fiori rollout stalled and nobody owns the launchpad" rescue is a Basis consulting engagement we know well. If your Fiori strategy questions are bigger than administration — central entry points, BTP, Work Zone — start with what SAP BTP actually is.
Related reading
- What Is SAP Fiori? — the design system and app family the launchpad hosts
- SAP Transport Management System (STMS): A Practical Guide — how launchpad content should move between systems
- What Is SAP Basis? — where Fiori administration sits in the Basis role