Fiori Launchpad Authorizations: Catalogs, Groups, and Business Roles

Explanation

In S/4HANA, end users primarily interact through the Fiori Launchpad rather than SAP GUI transaction codes, which changes how authorizations must be designed and tested. A Fiori app's visibility and functional access depend on multiple layers working together: the PFCG role assigned to the user, the catalog and group entries exposed in that role, the underlying OData or RFC service the app calls, and the backend authorization objects checked when that service executes. Catalogs are containers of tiles (apps) that are assigned to a PFCG role via the menu tab, typically referencing semantic objects and actions rather than direct transaction codes. Groups organize tiles for launchpad display but do not themselves grant authorization - they are purely presentation. This distinction matters: removing a tile from a group does not remove access to the underlying app if the catalog assignment or backend authorization still permits it. Business roles are PFCG roles specifically curated for Fiori scenarios, often built as single roles per job function or as composite roles aggregating several single roles, then assigned to Business Catalogs delivered by SAP as templates that customers copy and adapt rather than modify directly. A critical technical point is that launchpad tile visibility is a UX convenience, not a security boundary. Even if a tile is hidden, a user who has the underlying OData service authorization and backend authorization objects can potentially invoke the app through a direct URL or another entry point. Genuine access control happens at the backend: OData services are protected by authorization objects that mirror or extend classic object logic, and Gateway or Business Server Page components enforce checks when the service is called. This means Fiori authorization design must always trace from the tile back to the OData service name and then to the authorization objects checked inside that service's implementation - skipping this step and relying only on catalog/group assignment is a common and serious gap. For S/4HANA on-premise and private cloud, administrators typically use the Fiori apps reference library or system catalogs to identify which OData services and authorization objects back a given app, then build roles bottom-up from that information. In S/4HANA Public Cloud, the underlying configuration is more restricted; customers work primarily with SAP-delivered business catalogs and business roles through the Identity and Access Management app, with less direct object-level tailoring, since backend role maintenance is largely abstracted from the customer. BTP-based extension scenarios introduce a separate identity and authorization layer (role collections and role templates in BTP cockpit) that is independent of backend PFCG roles, so a Fiori app built as a BTP extension may require authorization mapping in two separate systems, not one. Testing Fiori authorizations requires validating both the launchpad experience (can the user see and open the tile) and the functional depth (can the user perform create, change, or approval actions once inside the app), since many Fiori apps use a single OData service for multiple operations gated by different authorization objects and field values inside the same call.

Code example

* Example: authorization object embedded in an OData service implementation* This illustrates the backend check a Fiori app performs after tile launch METHOD get_entityset.  AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'    ID 'BUKRS' FIELD ls_filter-company_code    ID 'ACTVT' FIELD '03'.  " 03 = Display   IF sy-subrc <> 0.    " Authorization failure: raise OData-compliant error    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception      EXPORTING        message = 'No display authorization for company code'.  ENDIF.   " Proceed to fetch and return entity set dataENDMETHOD.

Real project scenario

A finance user reported that a Fiori app tile was visible on their launchpad but clicking it returned an empty results screen with no error. The Basis-security team initially assumed a catalog assignment problem and re-added the tile to another group, which had no effect. Root cause analysis traced the app to its underlying OData service, then to the authorization object checked for company code display, revealing the user's role had been scoped to only two company codes during a recent role redesign while their job now covered five. The fix was adding the missing company codes to the role's authorization values, not touching the launchpad catalog or group at all - reinforcing that tile-level changes rarely solve backend authorization symptoms.

Common mistakes

• Assuming removing a tile from a launchpad group revokes access, when the underlying OData service authorization still permits the action through other entry points • Modifying SAP-delivered business catalogs directly instead of copying them, causing loss of changes on the next SAP update • Granting broad OData service authorization without restricting field-level values such as company code, plant, or sales organization inside the authorization object • Treating BTP role collections and backend PFCG roles as the same security layer when they are managed and audited independently • Failing to test the full transaction lifecycle within an app (create, submit, approve) and only validating that the tile opens

Best practices

• Always trace a Fiori app from tile to OData service name to backend authorization object before concluding a security design is complete • Copy SAP-delivered business catalogs and business roles rather than editing standard content directly • Test full in-app workflows, not just tile visibility, during authorization validation • Maintain a mapping document linking apps, OData services, and authorization objects for audit and troubleshooting reuse • Treat BTP role collections as a separate control domain requiring its own review cadence and documentation

Interview angle

Interviewers assess whether candidates understand that Fiori security is layered, not single-point. A strong answer distinguishes catalog and group as presentation-layer constructs from OData service and backend authorization object as the actual enforcement layer, and explains how to trace an app's tile back to its authorization checks using the apps reference library or technical app details. Candidates should also be able to describe differences between on-premise role-building flexibility and public cloud's more templated business role model.