Derived Roles, Composite Roles and Org-Level Value Maintenance

Explanation

Derived roles and composite roles solve two different problems in PFCG role architecture. A derived role is created in PFCG by referencing a master (reference) role. The derived role inherits the menu structure and all authorization objects and their values from the master, except for fields marked as organizational levels (org levels), such as company code, plant, purchasing organization or sales organization. This lets a security team build one master role for a job function (for example, Accounts Payable Clerk) and then create multiple derived roles - one per company code or region - without duplicating the menu or re-entering non-org-level authorization values. When the master role's menu or non-org authorizations change, all derived roles inherit the change automatically once the master is regenerated and the derived roles are updated (a required manual or scripted step in most projects; it is not always fully automatic depending on how transport and regeneration are managed). Org levels are fields flagged in the authorization object's technical settings as organizational, which causes PFCG to present them separately at the derived-role level, distinct from the master role's authorization value maintenance screen. A common mistake is forgetting that changing an authorization field's org-level flag mid-project (via the org-level field configuration) affects existing roles inconsistently and requires a role-by-role reconciliation, so this decision should be made early in the design phase, not after roles have proliferated. Composite roles, by contrast, do not have their own authorization data. A composite role is simply a container that references multiple single roles or derived roles, and when assigned to a user, the user receives the authorizations of all referenced roles combined. Composite roles are typically used to simplify user administration - for example, a 'Finance Onboarding' composite role that bundles a GL viewer role, an AP clerk role, and a reporting role, so provisioning teams assign one object instead of three. Composite roles must not be confused with derived roles; a very common junior mistake is trying to add org-level restrictions inside a composite role, which is not possible because composite roles have no authorization value maintenance screen of their own - restrictions belong only in the single or derived roles it references. Design guidance from real projects: use derived roles when the job function is identical but the organizational scope differs (multi-company-code rollouts, multi-plant manufacturing sites). Use composite roles when you need to bundle unrelated job functions for a persona but want to retain the ability to independently update each underlying role. Avoid deeply nested composite-of-composite structures; SAP supports composite roles referencing single/derived roles, and stacking multiple layers becomes very hard to audit, trace and troubleshoot when access issues arise, and reviewers in a GRC access review often cannot cleanly interpret nested inheritance. From a governance and audit standpoint, derived role structures make org-level segregation cleaner (auditors can see 'AP Clerk - Company Code 1000' as a distinct role with distinct assignments), which is usually preferable to a single flat role with a huge org-level value list, because it supports better segregation-of-duties analysis and easier user access review sign-off by business owners scoped to their org unit.

Code example

* PFCG role naming convention example used across derived structure* Master role: Z_FI_AP_CLERK_M (reference/master role, no org-level values filled)* Derived roles per company code:* Z_FI_AP_CLERK_1000 (derived, org level BUKRS = 1000)* Z_FI_AP_CLERK_2000 (derived, org level BUKRS = 2000)** Composite role bundling multiple single/derived roles for a persona:* Z_C_FI_ONBOARDING*   -> Z_FI_AP_CLERK_1000*   -> Z_FI_GL_VIEWER*   -> Z_FI_REPORTING_BASIC** Steps performed in PFCG (menu-driven, no ABAP required):* 1. Create master role Z_FI_AP_CLERK_M, build menu, maintain all*    non-org authorization values, generate profile.* 2. In master role Authorizations tab, use 'Role > Derive' or create*    derived role and reference the master.* 3. In each derived role, org-level fields appear editable; enter*    BUKRS value for that instance, then regenerate the profile.* 4. Create composite role, add single/derived roles under 'Roles' tab,*    no authorization maintenance is available at this level.

Real project scenario

A retail S/4HANA rollout covered 12 company codes across three countries. The security team initially built 12 separate flat roles for the AP Clerk function, each with a full copy of the menu and authorizations, which meant every menu change required 12 manual edits and regenerations. After a failed audit finding on inconsistent role content, the team refactored to one master role with 12 derived roles per company code, cutting maintenance effort significantly and giving auditors a clean one-to-one mapping between derived role and org unit for user access reviews.

Common mistakes

• Building flat, duplicated roles per org unit instead of using derived roles, causing maintenance drift over time • Attempting to restrict org-level values inside a composite role, which has no authorization data of its own • Nesting composite roles inside composite roles, making access hard to trace during audits and support tickets • Changing an authorization field's org-level flag mid-project without reconciling existing derived roles • Forgetting to regenerate and re-transport derived roles after the master role's menu or authorizations change • Assuming derived role menu changes propagate automatically without any manual step, when in most landscapes an explicit update/regeneration and transport is required

Best practices

• Use derived roles whenever the same job function repeats across multiple organizational values • Keep composite roles shallow (single level) referencing only single or derived roles, never other composites • Lock down org-level field decisions early in the design phase to avoid rework • Document the master-to-derived role mapping in the role design workbook for audit traceability • Establish a change process that always regenerates and transports derived roles whenever the master role changes • Name derived roles with a clear suffix convention indicating the org-level value they represent

Interview angle

Interviewers often ask candidates to explain the practical difference between derived and composite roles and to justify when each should be used; a strong answer references org-level inheritance, maintenance overhead reduction, and auditability, plus explicitly states that composite roles carry no authorization data of their own.