Designing and Building PFCG Roles: Menus, Authorization Objects, and Organizational Levels

Explanation

Building a PFCG role correctly requires moving through several interdependent steps, and getting the sequence wrong is one of the most common sources of production access issues. The process begins with menu design: deciding which transactions, reports, or Fiori app references belong in the role based on a documented business process, not on a user's ad hoc request list. Every transaction added to the menu triggers SAP's authorization proposal mechanism (maintained via SU24), which suggests the authorization objects and default field values typically required for that transaction. These proposals are a starting point, not a guarantee of completeness or correctness — some transactions perform additional authorization checks in custom code or in follow-on function modules that SU24 proposals do not capture, so a security designer must cross-check with functional documentation, unit test traces, or a technical trace of the actual authorization checks during realistic testing. Once the menu is set, the 'Change Authorization Data' step on the Authorizations tab consolidates all proposed authorization objects into a single working profile draft. At this point the designer must make deliberate, justified decisions about field values: activity codes (create, change, display, delete) should be set to the minimum required for the business process the role supports, and organizational level fields (company code, plant, purchasing organization, sales organization, cost center, etc.) should be scoped narrowly rather than left open, unless the role is genuinely intended to be a cross-organization role with appropriate compensating controls. Yellow (open) fields must be resolved before generation; leaving fields as full-authorization wildcards without justification is a direct control weakness that audit and GRC risk analysis tools will flag. Organizational levels deserve particular attention because they are the mechanism SAP recommends for scoping a role to a specific business unit without altering the non-organizational authorization logic. When a role will be reused across many company codes or plants, the standard technique is to build one reference (parent) single role with organizational level fields left as parameters, then create derived roles per organizational unit; the derived roles pull all non-organizational values from the parent automatically and lock in only the organization-specific values. This avoids duplicating and separately maintaining dozens of near-identical roles, and it means a change to business logic in the parent (adding a transaction, adjusting a non-org field) propagates to all derived children after regeneration, rather than requiring dozens of manual updates. After authorization data is complete, generating the profile creates the technical authorization profile object tied to the role; this must be repeated any time authorization data changes. Assigning users on the User tab does not by itself update what the user can do — a user comparison step (individual or mass, depending on scale) must run to push the current profile into the user's authorization buffer. In productive support, a frequent troubleshooting scenario is a user reporting an authorization error for something that 'should' be covered by their assigned role: the first checks are (1) has the role actually been regenerated since the authorization data changed, and (2) has a user comparison run since the role was last assigned or regenerated. Only after confirming those should deeper trace-based troubleshooting begin. In S/4HANA, the same PFCG mechanics apply for on-premise and private cloud editions, with the addition that Fiori launchpad content (catalogs and groups, or business catalogs in newer models) must be included in the role menu for tiles to appear, and the backend OData service authorization objects must still be present in the authorization data for the app to function once launched — tile visibility and functional access are separate checks. Public cloud editions generally administer access through business role concepts in dedicated Fiori administration apps rather than direct PFCG maintenance; treat PFCG-specific steps described here as applicable to on-premise/private cloud unless your specific engagement confirms otherwise.

Code example

* Illustrative PFCG build sequence for a derived role scenario * Step 1: Build parent/reference roleROLE: Z_FI_AP_CLERK_TEMPLATEMENU: FB60 (Enter Incoming Invoice), FB03 (Display Document), MIRO (display only) * Step 2: Change Authorization Data* SU24 proposes objects such as F_BKPF_BUK (company code), F_BKPF_BLA (doc type)* Set activity fields deliberately:F_BKPF_BUK: ACTVT = 01,02,03 (create, change, display) - justified by processF_BKPF_BUK: BUKRS = '#' (organizational level left open in template) * Step 3: Generate profile on template (org field remains open, not usable directly) * Step 4: Create derived roles per company codeZ_FI_AP_CLERK_1000  -> derive from Z_FI_AP_CLERK_TEMPLATE, set BUKRS = 1000Z_FI_AP_CLERK_2000  -> derive from Z_FI_AP_CLERK_TEMPLATE, set BUKRS = 2000 * Step 5: Generate each derived role, assign users, run user comparison * Troubleshooting checklist when a user reports 'no authorization':* 1. Was authorization data changed after last generation? -> regenerate* 2. Was user comparison run after assignment/regeneration?* 3. Trace actual authorization objects checked at runtime for the exact*    transaction/service the user attempted, compare against role's profile

Real project scenario

During a retail company's S/4HANA private cloud rollout, the security team needed one accounts payable role usable across twelve company codes with slightly different approval thresholds handled elsewhere in workflow, not in the role. Rather than building twelve near-identical single roles, the team built one reference role with the menu and non-organizational authorization objects finalized and reviewed by the FI process owner, then generated twelve derived roles, one per company code, each scoped only to its BUKRS value. When the process owner later requested adding a new display-only transaction for month-end reconciliation, the change was made once on the reference role and propagated by regenerating the derived roles, avoiding a twelve-role manual update and the associated risk of inconsistent scoping.

Common mistakes

• Accepting SU24 authorization proposals as complete without validating against actual runtime behavior for complex or custom transactions • Leaving organizational level or activity fields as open/wildcard values without documented business justification • Forgetting to regenerate the role profile after changing authorization data, leaving users on a stale profile • Forgetting to run user comparison after assignment or regeneration, causing 'the role looks right but the user still gets an error' support tickets • Building near-duplicate single roles per organizational unit instead of using the derived role mechanism, creating a long-term maintenance burden

Best practices

• Design the role menu from documented business process steps, not from a user's personal transaction wish list • Validate SU24-proposed authorization objects against real testing or trace evidence before finalizing field values • Use derived roles for any role that must be scoped identically except for organizational level values • Always regenerate the profile after any authorization data change and immediately run user comparison • Document the justification for any field left open or set broadly, so audits and GRC risk reviews have a clear rationale on file

Interview angle

Interviewers often probe whether a candidate understands the practical difference between generating a role profile and running user comparison, since confusing these two steps is a very common real-world support mistake. Candidates should also be able to explain when and why to use derived roles versus building separate single roles, and how SU24 proposals relate to, but do not guarantee, complete authorization coverage.