SAP Fiori Authorizations Tutorial (Part 1)

SAP Fiori changed how authorizations are structured compared to classic SAP GUI transactions, and this is the single most common source of confusion for consultants new to Fiori security. In classic ECC, a user typically needed one PFCG role containing a transaction code and the relevant authorization objects, and that was largely sufficient. Fiori splits this into two distinct layers that both must be satisfied before a user can successfully open and use an app.

The first layer is the front-end layer, which lives in the Fiori launchpad. This includes catalogs (collections of tiles and target mappings), groups (how tiles are visually organized for the user), and business roles or PFCG roles that reference these catalogs and groups. If a user does not have a role assigning them the correct catalog, they will simply not see the tile on their launchpad at all. This is a visibility and navigation control, not a data control.

The second layer is the back-end layer, which is the actual business authorization enforced when the app runs. This includes classic SAP authorization objects (in ECC and S/4HANA on-premise) and, for OData-based apps, additional checks tied to the service and its underlying business logic. Even if a user can see and click a tile, if their back-end authorizations do not permit the action - for example, displaying a sales order or approving a purchase requisition - they will get an authorization error once the app tries to fetch or post data.

A critical concept for beginners is that these two layers are independent. It is entirely possible to assign a user a catalog with no matching backend authorization, resulting in a tile that opens but shows only error messages or empty data. It is equally possible to have full backend authorization but no catalog assignment, meaning the tile never appears, and the user cannot find the app despite having rights to use it if they somehow launched it directly via URL.

In S/4HANA, most standard Fiori apps come with SAP-delivered business catalogs and business roles as templates. These are meant as a starting point, not a production-ready security model, because they are often broader than a real least-privilege design should be. A common project pattern is to copy these SAP-delivered catalogs and roles into a Z or Y namespace, then trim tiles and restrict authorization values (such as company code, plant, or purchasing organization) to match the organization's actual segregation of duties requirements.

Another beginner-level concept is the distinction between transactional apps (which usually map to a classic transaction or a BOR/business object and use familiar authorization objects), analytical apps (which often rely on CDS view-based authorizations and analytical privileges), and factsheet apps (which are typically read-only and simpler from an authorization perspective, though they still require an authorization object check).

Finally, beginners should understand that Fiori authorization work is fundamentally a cross-functional exercise. It requires collaboration between security/GRC teams (who own role design and least privilege), functional teams (who understand which fields and organizational levels matter for a given process), and Basis/technical teams (who manage system configuration, ICF services, and gateway or front-end server setup). Treating Fiori authorizations as a pure Basis or pure security task, without functional input, is a frequent root cause of either overly broad access or, on the other extreme, tiles that never work correctly for end users.

During a S/4HANA rollout, a finance user reports that the Manage Journal Entries tile is visible on their launchpad but clicking it produces a message that no line items can be displayed. Investigation shows the user's PFCG role correctly includes the launchpad catalog for the tile, but the backend role assigned to that same user was never updated with the correct company code authorization for the new entity being rolled out. This is a textbook case of the front-end layer being correctly configured while the back-end layer lags behind, and it is resolved by adding the missing organizational value to the backend authorization role, not by touching the launchpad configuration at all.

• Assuming that removing a tile from the launchpad catalog removes the user's ability to perform the underlying action; it only removes the navigation entry, not the backend authorization.
• Copying SAP-delivered business roles into production without reviewing and restricting the scope of authorization values.
• Troubleshooting a 'tile not appearing' issue by looking at backend authorization objects instead of checking catalog and group assignment first.
• Assuming a single PFCG role change fixes both layers when in practice front-end and back-end assignments are often maintained through separate composite or single roles.
• Not involving functional teams when defining which organizational levels (company code, plant, sales org) should scope a given app's access.

• Always verify both catalog/group assignment and backend authorization values when troubleshooting or designing access for a new app.
• Start from SAP-delivered business catalogs and roles as templates, but copy and restrict them rather than using them directly in production.
• Document, for each app in scope, which authorization objects and organizational levels are relevant, so functional and security teams share a common reference.
• Keep front-end (launchpad) roles and back-end (authorization) roles as separate role types where the organization's role design pattern supports it, to allow independent lifecycle management.
• Test with a representative end-user profile, not just a superuser, before go-live.

Interviewers commonly ask candidates to explain why a Fiori tile might be visible but not functional, or functional but not visible, to test whether the candidate genuinely understands the two-layer model rather than treating Fiori security as 'just another PFCG role.' Being able to clearly separate front-end catalog/group visibility from back-end authorization object enforcement, and to describe a realistic troubleshooting sequence, is a strong signal of hands-on project experience versus theoretical knowledge only.