SAP Catalogs

A catalog groups a set of Fiori apps (with their tiles and target mappings). It represents "these apps are available"; it does not by itself put tiles on a user’s home, that is what groups do. A role references catalogs to grant access to their apps and groups to arrange the visible tiles.

Where catalogs are maintained is worth knowing before looking for them: the Fiori launchpad designer, reached as an application rather than as a SAP GUI transaction, with separate configuration and customising layers. Changes there are recorded on transports like any other configuration, which is what makes launchpad content promotable between systems.

• Catalog: the pool of apps a user is authorised to launch (and can add as favourites).
• Group / page / space: the arranged tiles the user actually sees by default.

A catalog is not a list of apps. It holds two kinds of object, and confusing them is the source of the most puzzling Fiori symptom.

A tile is the visual: the title, the subtitle, the icon, and for a dynamic tile the service that supplies its number. It is what appears on the page.

A target mapping is the wiring: it maps a semantic object and an action, such as SalesOrder and display, to an actual application and how to launch it. It is what happens when the tile is clicked.

They are separate objects and a catalog can contain either without the other. A tile with no target mapping is a button that does nothing when clicked. A target mapping with no tile means the app is reachable by search and by navigation from other apps, and has no tile of its own, which is deliberate for apps only ever opened from somewhere else.

That second case is worth understanding, because a great many standard apps exist to be navigated to rather than launched. An order detail app opened from a list does not need a tile, and giving it one clutters the launchpad.

The semantic object and action mechanism is also what makes intent-based navigation work: an app can say "navigate to display this sales order" without knowing which app does that, and the target mapping the user holds decides.

Administrators use standard SAP-delivered catalogs (aligned to business roles) or build custom ones, then reference them from PFCG roles. SAP provides a Fiori apps reference library to find which catalog/role a given app belongs to, invaluable when setting up access.

The rule that matters: copy delivered catalogs into the customer namespace before changing them. Editing a delivered catalog works until an upgrade overwrites it, and the change vanishes without anybody connecting the two events. Copying also lets you trim, since delivered business catalogs are deliberately generous.

Twenty minutes, and it makes the model concrete.

1. Find a working app on a test user's launchpad and note which role granted it.
2. Open that role and find the catalog carrying the app.
3. Inside the catalog, find both the tile and the target mapping for that app. Note they are separate entries.
4. Remove the tile and keep the target mapping. Log in again: no tile, and the app is still findable by search.
5. Restore the tile and remove the target mapping instead. The tile is there and clicking it does nothing.
6. Restore both.

Steps four and five are the two symptoms people report as the same problem, and doing them once means never confusing them again. See tiles for the display side.

The catalog/group/role model is exactly what determines whether a user can find and open an app. Most "I can’t see the app" problems come down to the app’s catalog not being in the user’s role.

It matters for authorisation as much as for layout. The catalog is the front-end entitlement, and it is half of the pair: a user with the catalog and without the back-end authorisation sees the app and no data. Designing both together, in one role per job, is what avoids that mismatch. See the architecture for where each half is checked.

SAP ships a large volume of catalogs, groups and business roles, and knowing how to use them saves building from nothing.

Technical catalogs contain every app for an area, with their target mappings. They are the pool, they are not meant to be assigned to users, and they are where you find what exists.

Business catalogs are curated subsets intended for assignment, grouped around a job function.

Business roles assemble business catalogs and their spaces into something resembling a job, and they are the intended starting point for a customer role.

The recommended route is to copy a business role into the customer namespace, then trim. Delivered roles are deliberately generous, covering everything somebody in that role might do in any industry, so most of the work is removal rather than addition.

What not to do is assign delivered roles directly. They change with upgrades, they are wider than any real job, and any adjustment you make is overwritten. The copy costs minutes and the discipline is what keeps the launchpad stable across releases.

• How granular. One catalog per job function assigns cleanly. One giant catalog cannot be granted selectively, and one per app is unmanageable at scale.
• Copy or reference delivered content. Copy into the customer namespace, always, because delivered content is replaced on upgrade.
• Who owns them. Catalogs are security objects and layout objects at once, so the owner sits between the security team and whoever owns the user experience.
• How new apps get added. A defined route, or catalogs grow by request until nobody knows what a role permits.

Catalog problems present as a handful of symptoms, and working through them in order resolves most without opening configuration blindly.

Confirm what the user actually has. Read their assigned roles rather than asking them what they think they should see.

Find the app in a catalog on one of those roles. Not in one means no access, and no amount of page design will produce a tile.

Check the tile and the target mapping separately. Both in the catalog, or the symptoms above.

Check the space or group. Access without placement means findable by search, no tile.

Check the back end authorisation. Tile present, app opens, no data.

Check the OData service is active. Tile present, app opens, error rather than empty list.

Ask about personalisation. A user who hid a tile themselves sees a different launchpad from the design, and resetting theirs is the fix.

Seven checks, in that order, and the first three cover the large majority.

• Confusing catalogs (available) with groups (visible).
• Not using the Fiori apps reference library to find catalogs.
• Custom catalogs when a standard one exists.

• Editing a delivered catalog. The next upgrade replaces it.
• A tile without its target mapping. It appears and does nothing, and the two are maintained separately.
• One enormous catalog for everything. Access then cannot be granted selectively, which defeats the point of catalogs. See Fiori apps and UI5 for what they contain.

• Assigning delivered business roles directly. They are wider than any real job and they are replaced at upgrade, taking your adjustments with them.

Assigning a catalog is straightforward, and designing the catalog and role structure so each job gets exactly its apps is the part you do in the course.

If one thing is worth remembering: a catalog grants access and a tile displays it, and they are separate objects inside it. The two failure modes look similar to the user and are fixed in different places.