Fixing a Missing Fiori Tile

A visible tile is not one object, it is the end result of several independent configurations lining up at the same time: a catalog entry (or, in the space and page model, a business catalog assigned to a space) containing a tile definition and a target mapping, a PFCG role that carries that catalog or business role, a group or page assignment that puts the tile on the user's home screen, backend authorization objects that let the user actually call the target application, and a running OData service or UI5 application behind an active ICF node. Each of these is maintained in a different place, often by different teams. The structural fact that explains most confusion: every one of these can be individually correct and the tile still will not appear, because the failure is almost never inside any single piece, it is in the link between two of them.

This troubleshooting approach applies whenever a specific user or role reports that an app they expect to see is missing from the launchpad, or a newly transported catalog does not show up after go-live, or a tile appeared for some users and not others. It is the wrong approach when the complaint is that the app opens but shows wrong or empty data, or throws an error after launch, because at that point the tile has already resolved correctly and the problem has moved from launchpad configuration into the application or OData service itself. It is also the wrong first move to jump straight into recreating the catalog or the tile from scratch; that treats a symptom, and if a target mapping conflict caused the problem, duplicating the tile usually produces two ambiguous entries instead of one working one.

Above the launchpad sits the end user's browser and their personalization state, which can hide a tile independently of any backend configuration. Below the launchpad sits PFCG role design, which assigns catalogs, business catalogs, groups, spaces and pages to users, and below that sits the ABAP or embedded Gateway layer, where OData services must be registered and active and ICF nodes must be running. The classic catalog and group model and the newer space and page model coexist on many systems, since spaces were introduced as the intended replacement for group-based navigation without immediately deprecating catalogs and groups underneath. Troubleshooting a tile means walking down this stack from what the user sees, through what their role grants, to what the backend actually exposes, since a break can sit at any layer and the symptom looks identical from the top regardless of where it originates.

A finance user reports that an approval app tile that colleagues see is missing from their launchpad. First check is the role assignment in the user's identity record: the user does have the relevant business role. Second check is the business catalog itself: it is correctly assigned to that business role, and to the space the role points to. Third check, since the first two look fine, is authorization: running the authorization trace for that user while attempting to reach the app directly by URL shows a failed check on the object that governs UI application starts, because a recent role change removed the specific value for that app's technical name while keeping the wildcard for others. The catalog assignment made the tile theoretically available, but the missing authorization value meant the launchpad's own visibility check silently dropped it rather than showing an error. Adding the correct value back to the role and having the user log off and back on resolves it. No code change, no transport, no cache clearing was needed, because the break was a single authorization object value.

The classic catalog and group model still works on current S/4HANA but the space and page model is the direction SAP has been pushing launchpad configuration toward, and new implementations are generally advised to build on spaces and pages rather than groups. Under a clean core approach, tile and catalog configuration should live in standard configuration transport paths rather than manual changes directly in production, and any custom tile pointing at a custom OData service should be built as an extension rather than a modification to a standard catalog, so it survives an upgrade without needing to be re-checked against standard content changes.

This sits with Basis and security administration first, since role, catalog and authorization assignment are the majority cause. Functional consultants get pulled in when the underlying issue is a missing business role design decision, and development only gets involved when the OData service or UI5 application itself is broken. A clean handover states which layer was checked, what was found, and what was actually changed.

Read the page on Fiori launchpad catalogs, groups and spaces before this one if the classic versus space-based model distinction is unclear, since most tile visibility troubleshooting depends on knowing which model the affected role actually uses and where its content assignments live.