Fiori Launchpad Catalogs Groups and Spaces Explained

A catalog is a container of tiles and target mappings. It links a tile's icon and title to a technical target: an OData service, a UI5 application, a transaction, or a web dynpro object, and it is assigned to users through a PFCG role. Assigning a catalog to a role gives a user the authorization to launch the app behind that tile, but it does not put the tile anywhere on their screen. A group, in the classic launchpad model, is the user-facing collection of tiles that actually appears on the home page; groups are also assigned via roles, or built by end users as personal groups. Spaces and pages are the newer replacement for groups: a space represents a business role or scenario, contains one or more pages, and each page has sections that reference tiles defined in a catalog. The confusion nearly every ticket traces back to is this split between the authorization layer and the presentation layer, and the fact that both classic and newer structures can be live in the same system at once.

Reach for a catalog when defining or reusing the technical building block for an app: which OData service it calls, which semantic object and action it resolves, which authorization object gates it. Reach for a group, or a space and page, when the job is arranging what a specific business role sees on login and in what order. Do not try to give end users access by handing them a catalog directly; in most configurations catalogs are not meant to be user-visible entry points, they are administrative plumbing. Do not manage per-user tile layout by editing individual users' personal groups at scale; use role-based default content instead and let personalization handle individual variation. On a net-new S/4HANA build, do not start with the classic group model out of habit; spaces and pages are the current standard and retrofitting later is more work than starting there.

Above catalogs and groups sits the PFCG role, which is the unit of assignment presented to users and mapped to positions or business roles in identity management. Below catalogs sit the actual app artifacts: the UI5 application descriptor, the OData service and its ICF node, or the classic transaction being wrapped. A tile in a catalog is just a pointer into that layer. In the space-based model, a page's sections reference catalog tile IDs rather than duplicating the tile definition, so the catalog remains the single source of technical truth even after groups are retired. At runtime, the launchpad's initialization logic merges every catalog and every group or space assigned across all of a user's roles into one rendered home screen, which is why role design and content design cannot be reviewed separately from each other.

A new business role, accounts payable accountant, needs a home screen with the invoice processing apps. The technical build starts with a catalog holding the tiles for those apps, either a copy of a standard SAP-delivered catalog or a custom one if a target mapping parameter needs to differ from the delivered default. That catalog is assigned to a PFCG role, which grants the authorization to launch each app. The presentation build then diverges depending on the model in use. In the classic model, a group named something like Accounts Payable is created, the relevant catalog tiles are added to it, and the group is assigned to the same role. In the space-based model, a space is created for the business role, a page is added to it, sections are built inside the page, and the catalog tiles are placed into those sections; the space itself is then added to the role's menu as a space assignment. A test user in that role logs on and the home screen is checked against what was intended; if a tile is missing, the first thing checked is whether it exists in an assigned catalog before touching the group or page at all.

Catalogs exist under the hood in both the ECC-era Fiori launchpad and in S/4HANA; they have not been replaced, only the presentation layer built on top of them has changed. The classic group model was the only option historically and is still supported, but spaces and pages are now the standard structure for new S/4HANA implementations, including cloud editions where the launchpad content model is largely fixed to this approach. Under clean core principles, custom catalogs, spaces, and pages should be built in a customer namespace and configured through the provided administration apps rather than by modifying SAP-delivered objects directly. In cloud editions, backend catalog editing is often restricted entirely, pushing all content management toward configuration rather than development.

Security and Basis own PFCG role design and catalog-to-role assignment. The functional or business process owner decides which apps belong together on a group or a page and in what order. A developer is only pulled in when a new target mapping, OData service, or custom tile needs to be created. Handover between them should always include the catalog ID, the semantic object and action, and the PFCG role name, not just a screenshot of the intended layout.

Read the tile visibility troubleshooting page next; it walks the actual checklist for a missing app and depends entirely on understanding the catalog-versus-presentation split covered here, since most missing-tile incidents are misdiagnosed as authorization problems when they are really a group or page assignment gap, or the reverse.