SAP Launchpad

The launchpad presents the apps a user’s roles entitle them to, as tiles grouped into pages/spaces, with search, favourites, recent activity and notifications. It gives a consistent, personalised home across all Fiori apps and devices, replacing the classic menu tree.

It is also the search entry point, and that is underrated. A user who cannot find a tile can usually find the app by name, because search covers everything their catalogs grant regardless of whether a tile exists. Telling people that is often a faster fix than redesigning a page.

• Tiles: launch apps; can show live KPI counts (dynamic tiles).
• Groups / pages / spaces: organise tiles by topic or role.
• Search & favourites: quick navigation.

Two models exist and knowing which a system uses saves confusion, because the concepts sit at different levels.

In the groups model, a role carries catalogs, which grant access, and groups, which arrange tiles into blocks on one long scrolling home page. It works, and with several roles a user ends up with a page of twenty groups nobody curated.

In the spaces and pages model, a role carries a space, which appears as a tab, and each space contains pages laid out in sections. A user with three roles gets three tabs rather than one endless page, and each tab is designed for one job.

Access is still granted by the catalog underneath, so the distinction is unchanged: catalogs decide what a user may reach, spaces and pages decide what they see and where. Search still finds an app the user has access to even if no tile exists for it.

Spaces are the current direction and older landscapes still run groups, so the practical question on any system is which is active, because the configuration path differs entirely.

Migration between the two models is a real project rather than a switch. Existing groups can be converted into spaces and pages, and the conversion produces a starting point rather than a design. The opportunity is to curate at the same time, since the reason to move is usually that the group-based home page had grown unmanageable.

Twenty minutes, and it is the most common launchpad support call.

1. Confirm what the user actually has. Look at their assigned roles rather than asking them.
2. Check the catalog. If the app is not in a catalog on one of those roles, there is no access, and no amount of page configuration will produce a tile.
3. Check the space or group. Access without a tile means the app is reachable by search and has no place on the page.
4. Check the OData service is active. An app with an inactive service produces a tile that opens and errors, which is a different symptom worth distinguishing.
5. Ask whether the user personalised their launchpad. Hidden tiles are a user-level setting, and resetting personalisation is the fix.

Five checks in order. The first three cover most cases, and knowing which of them failed tells you whether it is a security question or a layout one.

What appears on the launchpad is driven by the user’s PFCG roles, which reference Fiori catalogs (available apps) and groups (arranged tiles). This is why launchpad content is administered through the role/catalog model, and why missing tiles are almost always a role/catalog issue.

The design implication is worth stating: a launchpad is only as good as the roles behind it. Roles built as "everything this department might need" produce a cluttered launchpad, and roles built around a job produce a usable one. That makes launchpad design and role design the same conversation rather than two.

Users personalise their launchpad, favourite apps, arrange tiles, so their most-used apps are front and centre, a key adoption driver.

Personalisation has an operational consequence that catches teams out. Once a user has personalised, some changes an administrator makes centrally no longer reach them, because their own arrangement takes precedence. Communicating a change and, where necessary, resetting personalisation is part of rolling out a new page rather than an afterthought.

The launchpad is the first thing a user sees, so it is where impressions of the whole system are formed, and it has its own performance characteristics worth knowing.

Dynamic tiles cost calls. Every tile showing a live count calls its OData service when the page loads. Twenty such tiles is twenty calls before the user has clicked anything, and on a busy system that is felt.

Caching matters more here than elsewhere. The launchpad loads a great deal of metadata about apps, catalogs and pages. Where caching is misconfigured, that is fetched every time.

Roles affect load. A user with many roles has more catalogs to resolve, so the person with the widest access has the slowest experience, which is usually a manager.

The practical measures are curating tiles rather than accumulating them, setting sensible refresh intervals on dynamic ones, and pointing counts at services designed to be cheap rather than at a full list query. None of these are difficult, and they are usually done after somebody complains.

Launchpad content is configuration, and knowing where each piece is maintained saves a great deal of searching.

Catalogs and groups, or spaces and pages, are maintained in the launchpad designer and assigned through roles in PFCG. So a content change is a role change, and it moves between systems as a transport like any other.

Target mappings inside a catalog are the piece people miss. A tile is the visual; the target mapping is what says which application that intent actually launches. A tile with no target mapping is a button that does nothing, and the two are maintained separately.

Personalisation lives per user and is not transported, which is why a user can look different from the design after any change.

The operational consequence is that rolling out a launchpad change is a release rather than an edit: transport the role, communicate the change, and be ready to reset personalisation for anyone whose own arrangement now hides what you added.

• Missing tiles from role/catalog gaps.
• Overcrowded launchpad from poor grouping.
• Ignoring dynamic tiles/KPIs that add value.

• Adding tiles rather than curating them. A launchpad grows by request and nobody removes anything, which is how it becomes the menu it replaced.
• Dynamic tiles pointing at expensive services. Every tile calls its service on load, so a page of twenty live counts is twenty calls before the user does anything. See Fiori performance.
• Assuming a missing tile is a bug. See the Fiori introduction for the access chain and OData for what the apps talk to.

• A tile with no target mapping. It appears and does nothing, because the visual and the intent it launches are maintained separately.
• Rolling out spaces without deciding what happens to existing personalisation. Users keep their old arrangement and never see the new page.

Finding an app is the easy half, and designing spaces, pages and the roles behind them so each job gets a launchpad that fits it is the part you do in the course.

If one thing is worth remembering: a catalog grants access and a group or space arranges tiles. Missing access and missing tile look similar to the user and are entirely different problems.