Designing PFCG Roles for Fiori: Catalogs, Groups, and Backend Alignment
Learn the practical role design workflow for Fiori: how to build or adapt PFCG roles that bundle front-end catalogs and groups with the correct backend authorizations, including OData service authorizations and organizational-level restrictions.
Explanation
Once a consultant understands that Fiori requires both a front-end (launchpad) layer and a back-end (authorization) layer, the next step is learning the practical mechanics of designing PFCG roles that deliver both correctly and in a least-privilege way. This is where most day-to-day Fiori security work actually happens. In PFCG, a role intended to support Fiori apps typically has menu entries pointing to catalogs and groups on the Menu tab, in addition to (or instead of) classic transaction codes. When you add a catalog to a role's menu, PFCG can pull in the associated authorization default values much like it does for transactions, but this is not fully automatic for every object - the security designer must still review and, in many cases, manually add or adjust authorization objects, especially organizational-level restrictions such as company code, plant, sales organization, or purchasing organization, since SAP-delivered defaults are usually broad by design. A key technical detail is that Fiori apps built on OData services require an additional authorization check tied to the service itself in many scenarios, beyond the classic business object authorization objects. This means that even a well-scoped classic authorization object set may not be sufficient; the OData service exposure and its associated authorization checks (often tied to the same or related authorization objects used by the underlying business logic, but sometimes with service-specific checks) must also be validated. In S/4HANA on-premise and private cloud, this is typically managed through the same PFCG role-building process, since the backend authorization objects used by the business logic behind the OData service are usually the same ones used by the classic transaction equivalent, if one exists. A practical, repeatable role design workflow looks like this: first, identify the target apps and their associated SAP-delivered business catalogs and business roles as a reference. Second, copy the relevant catalogs into a customer namespace only if UI-level customization (tile visibility, grouping) is required; otherwise, many projects reference SAP-delivered catalogs directly and control access purely through role assignment, since catalogs themselves are not typically the layer where sensitive restriction happens - that is usually the backend authorization objects. Third, build or extend backend authorization roles using the standard authorization objects relevant to the business process, restricting organizational levels according to the user's actual job scope. Fourth, combine front-end and back-end pieces into a role concept - either as a single composite role per business function, or as separate front-end and back-end roles assigned together to each user, depending on the organization's chosen role architecture. Fifth, test end-to-end with a realistic test user before assigning broadly. Another important intermediate-level concept is the difference in role maintenance between on-premise/private cloud S/4HANA, where security teams have full PFCG access and can freely copy, edit, and restrict SAP-delivered roles, versus S/4HANA public cloud, where role design is typically done through business catalogs and business roles in a more templated, configuration-driven way with less direct low-level authorization object editing, since SAP restricts direct access to some underlying technical layers in that deployment model. Consultants moving between on-premise and public cloud projects need to recognize that the same conceptual model (front-end catalog plus back-end authorization) applies, but the tooling and degree of granular control differ significantly. Finally, role design for Fiori must account for the fact that many apps share underlying authorization objects with classic transactions. This means a poorly scoped Fiori role can inadvertently grant broader classic transaction access than intended if the same authorization object also controls that transaction, and conversely, restricting an authorization object too aggressively to satisfy a Fiori app's needs can break an unrelated classic transaction that the same user still requires. This overlap must be explicitly checked during design, not assumed away.
Real project scenario
A project team is rolling out the Manage Purchase Orders app to a regional procurement team. The team copies the SAP-delivered business catalog into a custom catalog to remove tiles for supplier evaluation that are out of scope for this rollout, then builds a backend authorization role restricting purchasing organization and purchasing group values to the region's own organizational units. During testing, a test user with the new role can see and open the app but cannot release purchase orders above a certain value, which after investigation turns out to be an intentional restriction correctly reflecting the release strategy, confirming the role design is working as intended rather than indicating a defect.
Common mistakes
• Relying entirely on SAP-delivered default authorization values pulled into PFCG without manually reviewing and restricting organizational levels. • Forgetting that OData service-level checks can exist in addition to classic business object authorization checks, and only testing the classic authorization objects. • Building one overly broad role to 'cover' multiple apps instead of scoping roles per business function, making least-privilege reviews difficult later. • Not checking for authorization object overlap between a new Fiori role and existing classic transaction roles assigned to the same users. • Assuming the public cloud role design process works identically to on-premise PFCG-based design when planning timelines or effort.
Best practices
• Treat SAP-delivered business catalogs and roles as a starting reference, and explicitly document any deviations made for the customer's environment. • Always restrict organizational-level authorization values rather than leaving SAP-delivered defaults (which are often set to full access) in production roles. • Validate both the classic authorization objects and any OData service-level checks relevant to the app before considering role design complete. • Check for authorization object overlap with existing classic transaction roles before finalizing scope, to avoid unintended access expansion or unintended breakage. • Maintain a clear mapping between apps, their catalogs, their key authorization objects, and the roles that grant them, to support future audits and role reviews.
Interview angle
Candidates are often asked to walk through the actual steps they would take to build access for a new Fiori app from scratch, including how they would scope organizational levels and validate the OData service layer, which tests whether they have hands-on PFCG and Fiori role-building experience rather than only conceptual awareness. A strong answer distinguishes catalog/group work from backend authorization object work and mentions end-to-end testing with a realistic test user.