Designing and Configuring S/4HANA Business Roles with PFCG: A Practical Walkthrough

Explanation

Designing an S/4HANA business role in PFCG follows the same core mechanics consultants use in ECC, but with additional steps to correctly wire up Fiori launchpad content and the corresponding backend authorization checks. A typical role-build process starts by identifying the business scenario a role must support — for example, an accounts payable clerk who needs to post and park vendor invoices for specific company codes. The role designer creates a single role in PFCG, adds the relevant Fiori catalogs and groups on the menu tab so the correct tiles appear in the launchpad, and then generates the authorization profile, which pulls in default authorization objects associated with the transactions and services referenced in the menu. A critical step is reviewing and adjusting the default values proposed for each authorization object. SAP's default check tables propose likely field values based on typical usage, but these defaults are frequently too broad (for example, proposing all activities or all company codes) and must be narrowed to reflect least privilege for the specific role. This is where the consultant explicitly restricts fields such as company code, plant, or activity to only the values the business role actually requires, removing display-only roles' ability to post, or removing a clerk's access to company codes outside their assigned scope. For organizational scoping across multiple company codes, plants, or sales organizations, the standard approach is to build a single master/derived role structure: a master role defines the menu and non-organizational-level authorization values once, and derived roles inherit that menu and non-org values while only varying the organizational-level fields (company code, plant, etc.). This avoids duplicating menu maintenance across many near-identical roles and keeps authorization value changes centralized in one place — a change to the master role's non-org fields propagates to all derived roles, reducing maintenance risk. In S/4HANA, this pattern still applies to backend business objects, but Fiori catalogs/groups are typically maintained at the role level consistently since launchpad content generally does not vary by organizational unit in the same way authorization values do. Before any custom role reaches production, testing must validate both dimensions: functional testing (can the test user complete the intended business process end-to-end through the Fiori app) and authorization testing (does the role correctly deny access outside its intended scope). A trace tool capturing actual authorization checks during a test session is the standard way to verify that no unnecessary broad authorization was granted, and that no required object was missed, before the role is transported and assigned. In S/4HANA Cloud Public Edition, this process is significantly different: administrators typically compose business roles from SAP-delivered business catalogs and business roles rather than freely building custom PFCG roles with full authorization-object-level control, since deep customization is restricted in that edition; the underlying principle of aligning launchpad content with authorization scope still applies, but the tooling and flexibility differ and must be verified against the specific tenant capabilities rather than assumed to mirror on-premise PFCG. Finally, role design decisions must always consider segregation-of-duties risk — for example, ensuring the same role does not combine invoice creation and invoice approval authorizations unless explicitly justified and compensating controls exist — because this is frequently one of the first things internal or external auditors review after go-live.

Code example

* Example PFCG-style authorization value narrowing (illustrative, not literal syntax)* Authorization Object: F_BKPF_BUK (Accounting Document: Authorization for Company Codes)*   Field: BUKRS (Company Code)      -> Value: 1000  (restricted, not '*')*   Field: ACTVT (Activity)          -> Value: 01, 02 (Create, Change) - remove 06 (Delete) for clerk role** Fiori OData Service Authorization Object (illustrative naming)*   Field: SERVICE                   -> Value: <App-specific service technical name>*   Field: ACTVT                     -> Value: 03 (Read) or as required by the app's operations** Derived role pattern:*   Master role: Z_AP_CLERK_MASTER   -> Menu + non-org authorization values maintained once*   Derived role: Z_AP_CLERK_1000    -> Inherits menu, sets BUKRS = 1000*   Derived role: Z_AP_CLERK_2000    -> Inherits menu, sets BUKRS = 2000

Real project scenario

A retail company migrating from ECC to S/4HANA private cloud needed new business roles for its accounts payable team. The project team built a master role with the Fiori catalog for invoice processing apps and the core business authorization objects, then created derived roles per company code to reflect the decentralized finance organization. During UAT, a trace revealed that the default-generated authorization for the OData service was too broad, allowing a supposed 'display only' tester to submit changes; the team narrowed the service's activity field and re-tested before the role moved to production.

Common mistakes

• Accepting SAP's proposed default authorization values without narrowing them to the actual business need. • Building a separate full role per company code instead of using a master/derived role structure, creating heavy long-term maintenance. • Forgetting to align Fiori catalog/group assignment with the actual authorization scope of the underlying OData service and business objects. • Skipping trace-based validation and relying only on 'the tile worked for me' functional testing. • Assuming the same PFCG-centric, fully customizable role-build process applies unchanged in S/4HANA Cloud Public Edition.

Best practices

• Always narrow default-proposed authorization values to the specific business need rather than accepting broad defaults. • Use master/derived role structures for organizational scoping to centralize non-org authorization maintenance. • Validate every new or changed role with a trace-based session covering realistic business transactions, not just a login check. • Explicitly review new roles for segregation-of-duties conflicts before go-live, documenting the review outcome. • Confirm whether the target environment is on-premise/private cloud (full PFCG flexibility) or public cloud (business role composition model) before committing to a design approach.

Interview angle

A frequent interview question is to explain the master/derived role pattern and why it matters for maintenance and audit. Strong candidates also explain how default authorization values from SU24-style proposals must be reviewed and narrowed, and can articulate at least one segregation-of-duties risk they would check for in an AP or procurement role, rather than describing role-building as a purely mechanical PFCG exercise.