Assembling Business Roles from Fiori Catalogs and Groups in PFCG

Explanation

Once technical catalogs and groups exist (typically delivered by SAP or copied/extended by the security team), the real design work happens when they are assembled into PFCG business roles that end users actually receive. A business role is not simply 'attach every catalog a user might need.' It is a curated bundle: one or more catalogs (which expose tiles/target mappings) plus one or more groups (which organize those tiles into a launchpad layout), tied to a PFCG role that also carries the backend authorization objects (S_SERVICE, S_START, and application-specific objects) required for the OData services and Fiori apps behind those tiles. In practice this assembly happens on the front-end server (or embedded Fiori front-end in newer S/4HANA releases) for the catalog/group/tile layer, while backend authorizations for the underlying business objects (sales orders, purchase requisitions, HR infotypes, etc.) are maintained in the corresponding backend PFCG role. In embedded deployment scenarios common in S/4HANA on-premise, front-end and backend content can live in the same system, but the authorization objects are still logically separate: launchpad-level (can the user see and start the tile) versus application-level (can the user actually read/write the data once the app opens). A critical design discipline is target mapping review. Each tile in a catalog points to a target mapping that resolves to a specific technical artifact - an OData service and application ID for transactional apps, an analytical query for KPI tiles, or a native UI5 application ID. If a business role includes a catalog whose target mappings reference apps the business process owner never approved, users get tiles they should not have, even if backend authorization would ultimately block the transaction. This is a usability and audit problem: unexpected tiles suggest scope creep and complicate access certification, even when no actual data exposure occurs. Groups control layout and grouping on the launchpad home page but do not themselves grant authorization - removing a group does not remove access, it only hides tiles from that particular grouping (though if the tile has no assigned group, it may not be reachable through normal navigation). This distinction is frequently misunderstood: teams sometimes 'fix' unwanted access by removing a group, believing they have restricted the user, when the same catalog still exposes the tile through search or another group, and the underlying OData authorization remains open. A sound assembly workflow is: (1) start from business process scope, not from available catalogs, (2) identify the minimum set of apps required for the role, (3) map each app to its owning catalog and confirm the target mapping resolves to the expected OData service/app ID, (4) assemble catalogs and one or more groups into a composite or single PFCG role, (5) generate backend authorization data for the same role using the authorization default values proposed by the app's PFCG object list (adjusted to organizational scope such as company code or plant), (6) test end-to-end as a representative user before promoting to production. For public cloud S/4HANA, the equivalent activity happens through the SAP-delivered business role templates and the Maintain Business Roles app, which restricts direct PFCG editing and instead exposes catalog/group assignment through a managed UI, but the same logical separation between launchpad content and backend scope still applies conceptually. Role naming conventions matter operationally: teams that name PFCG roles after job functions (for example, a role representing 'AP Clerk') rather than after individual catalogs make recertification and mass changes far easier, since auditors and business owners can review one role name tied to one job function rather than reverse-engineering intent from a list of catalog technical names.

Code example

* Illustrative PFCG role authorization object list entries after catalog/group assembly* (values are illustrative examples, not universal defaults) Role: Z_BR_AP_CLERK  (Business role: Accounts Payable Clerk) --- Menu tab ---Catalog: SAP_FI_BC_AP_CLERK      (or custom Z_CAT_AP_CLERK)Group:   Z_GRP_AP_CLERK_HOME --- Authorizations tab (backend, generated) ---S_SERVICE  SRV_NAME  = <OData service technical name for the invoice app>  SRV_TYPE  = HT S_START (Fiori launchpad start authorization for the app)  APPID     = <UI5 application ID> F_BKPF_BUK (financial document, company code restriction)  BUKRS     = 1000, 2000   " scoped to org units the clerk actually supports  ACTVT     = 01, 02, 03 * Verification checklist before transport to production:* 1. Confirm target mapping for each tile in the catalog resolves to an approved OData service* 2. Confirm S_SERVICE entries generated match services actually called by those tiles* 3. Confirm org-level restrictions (BUKRS, WERKS, etc.) reflect business scope, not SAP_ALL-style defaults* 4. Test as a dialog user with only this role assigned - no other roles masking gaps

Real project scenario

During an S/4HANA rollout, the finance workstream requested that AP clerks receive 'the standard invoice catalog' to save time. The security team assembled a business role directly from the SAP-delivered catalog without reviewing target mappings, and it later surfaced that the catalog also included a payment run monitoring tile intended for AP supervisors. Although the backend F_BKPF_BUK authorization blocked the clerks from executing certain actions, the tile itself was visible and clickable, causing help desk tickets and an internal audit finding about 'unexplained access to supervisor functions.' The remediation involved creating a scoped custom catalog (Z_CAT_AP_CLERK) containing only clerk-approved target mappings, reassigning it to the business role, and documenting the catalog-to-job-function mapping for future recertification cycles.

Common mistakes

• Assembling business roles by copying 'everything in the SAP standard catalog' instead of scoping to approved target mappings for the job function. • Believing that removing a group from a role revokes access, when the tile may still be reachable via search or another catalog/group. • Generating backend authorizations from defaults without adjusting organizational-level fields (company code, plant, sales org), leaving overly broad scope. • Naming PFCG roles after catalogs or technical artifacts instead of job functions, making recertification and audit review difficult. • Not testing the assembled role end-to-end with a representative test user before production transport, missing tile-to-authorization mismatches. • Assuming embedded S/4HANA deployment removes the need to separate launchpad-level and application-level authorization review.

Best practices

• Always validate target mappings for every catalog before including it in a business role - confirm the OData service/app ID is the one the business actually approved. • Design business roles around job functions, assembling only the catalogs and groups needed for that function's approved app list. • Generate and review backend authorization defaults for every included app; explicitly scope organizational fields rather than accepting wide defaults. • Treat group changes as UI/navigation changes only - never rely on group removal as an access control mechanism. • Maintain a living mapping document (job function to catalog to app to OData service) to support recertification and audits. • Test the finished business role with a dedicated test user holding only that role before promoting to production.

Interview angle

Interviewers probe whether candidates understand that catalogs/groups control launchpad visibility while PFCG authorization objects control actual data access, and that these are independently maintained but must be assembled coherently. Strong answers describe a scoping workflow driven by business process rather than by available SAP content, mention target mapping validation as a concrete control, and can explain why removing a group is not a security fix. Candidates should also be able to contrast classic PFCG-based role assembly with the public cloud Maintain Business Roles approach at a conceptual level.