The Fiori launchpad is the front door to S/4HANA — the shell every user passes through, the place where apps live as tiles, and the source of endless confusion about spaces, pages, catalogs, and groups. These concepts layer on top of each other, and mixing them up leads to the classic symptom: "I assigned the role but the tile doesn't show up."
Here's how the launchpad actually fits together, from the shell down to the tile.
The launchpad's role: shell, not app
The launchpad isn't an application — it's the operating shell for all Fiori apps. It provides the header bar (search, notifications, user menu, app finder), the navigation framework, and the runtime services every app relies on: intent-based navigation, personalization storage, bookmarking, and the app-to-app communication bus.
Think of it like a phone's home screen. The home screen doesn't do anything itself; it launches apps, organizes them, and provides system services (notifications, search, settings). The launchpad plays exactly that role for the enterprise: one consistent entry point, with the apps as interchangeable parts inside it.
This architecture is what makes intent-based navigation possible. Apps don't link to each other by URL — they declare intents (a semantic object plus an action, like SalesOrder-display), and the launchpad resolves each intent to the right app at runtime based on the user's roles. Swap the target app, and every link across the system follows without a single code change.
The launchpad's job: be invisible. Users should think in terms of tasks ("approve the order"), not in terms of the shell. When the launchpad draws attention to itself, something's wrong.
Spaces and pages: what the user sees
Spaces are the top-level organizing principle — one space per role or responsibility area. "Sales Manager," "Warehouse Clerk," "Finance Controller": each gets a space containing everything that role needs. Spaces appear as tabs or entries in the launchpad navigation; switching spaces switches context entirely.
Pages live inside spaces and hold the actual content: tiles, cards, and links arranged in sections. A Sales Manager space might contain pages for "Overview," "Orders," and "Analytics" — each page a curated working surface for part of the role.
The hierarchy is strict: spaces contain pages, pages contain sections, sections contain tiles/cards/links. Users can personalize within limits — rearranging, adding apps from the App Finder — but the administrator defines the structure. Personalization is stored per user; the delivered structure stays intact underneath.
This replaced the older groups model, where tiles sat in flat groups on a single home page. Groups still exist for compatibility, but spaces-and-pages is the current structure — hierarchical, role-shaped, and far better at handling the dozens of apps a real role needs.
Catalogs: what the administrator assigns
Here's the concept that causes the most confusion: a catalog is an administrative container, not something users see. Catalogs hold tiles and target mappings; administrators assign catalogs to roles (PFCG roles on-premise, business roles in cloud). Users never browse catalogs — they see the spaces and pages built from catalog content.
The flow works like this:
1. SAP delivers business catalogs — e.g., "Sales Order Processing" — containing the tiles and navigation targets for a functional area.
2. The administrator assigns business catalogs to roles. A role can reference multiple catalogs.
3. The administrator (or key user) builds spaces and pages pulling tiles from the catalogs the role can see.
4. The user opens the launchpad, sees their spaces, and launches apps. Catalogs are invisible throughout.
So when "the tile doesn't show up," the debugging chain is: is the tile in a catalog? Is that catalog assigned to the user's role? Is the tile placed on a page in one of the user's spaces? A break at any link hides the tile. Most often the culprit is step 2 — the catalog-to-role assignment — because it's the least visible link in the chain.
There's also a useful distinction between business catalogs (SAP-delivered, shouldn't be modified) and technical catalogs (the underlying target mappings and app descriptors the business catalogs reference). Custom tiles go in custom business catalogs that reference either SAP's technical catalogs or your own.
Remember: catalogs are for assignment (admin → role), spaces/pages are for presentation (role → user). Mixing up which layer you're working in is the root of most launchpad configuration headaches.
Tiles, cards, and links: the content
Tiles are the classic launchpad content — square app launchers, optionally showing live data (a KPI tile showing "47 open orders" with a trend arrow). Static tiles just launch; dynamic and KPI tiles preview information so users can decide whether launching is even necessary.
Cards are the newer integration-card format: richer than tiles, they can show lists, tables, charts, and even actions inline without opening the app. An approval card might show the three pending items with Approve/Reject buttons right on the launchpad. Cards are where the launchpad is heading — more done without leaving the home surface.
Links are the minimal form: plain text navigation entries for apps that don't merit a tile. Useful for rarely used transactions or for keeping a page compact.
All three resolve through target mappings — the technical records that bind an intent (semantic object + action) to an actual app (URL, component, parameters). The tile is the visible face; the target mapping is the wiring. When a tile is visible but clicking it fails, the target mapping is usually where to look.
Putting it together: a concrete example
A sales manager logs in. The launchpad shows their spaces: "Sales Operations," "Analytics," "Approvals." They open Sales Operations and see pages for "Orders" and "Customers." The Orders page shows KPI tiles (open orders, overdue deliveries), a card listing orders awaiting approval with inline approve buttons, and links to the full order apps.
Behind the scenes: SAP's "Sales" business catalogs are assigned to the Sales Manager business role. The administrator composed the spaces and pages from those catalogs' tiles. Each tile resolves through target mappings to Fiori apps via intents like SalesOrder-manage. The manager sees tasks; the machinery stays hidden.
When the company adds a custom "Commission Report" app, the developer creates a tile in a custom catalog, the admin assigns that catalog to the role and drops the tile onto the Analytics page. The manager finds it at next login.
Bottom line
Shell (the launchpad) → spaces (per role) → pages (working surfaces) → tiles/cards/links (content), with catalogs as the invisible assignment layer feeding roles. Learn that stack and the launchpad stops being mysterious — including the part where you debug why a tile isn't showing up.