PFCG Roles: Single, Composite and Derived Roles

PFCG generates authorization profiles from role authorization data. Single roles are the core authorization-maintenance unit. Composite roles simplify assignment of several single roles to a user, but changes still happen in the constituent single roles. Derived roles support organizations that need the same job function across company codes/plants/sales orgs: a master role holds common menu/authorization design, and derived roles inherit it while organization-level fields are maintained separately. User comparison updates user master/profile assignments after role changes.

Use single roles as modular job-function/technical entitlement building blocks. Use composites for convenient business-job assignment of stable single-role bundles, not for authorization maintenance. Use derived roles when many organizational variants genuinely share the same authorization structure and only organization values differ. Avoid derived roles when roles will diverge functionally over time; independent single roles may be easier to govern.

PFCG menu/catalog content influences Fiori/transaction access; SU24 supplies authorization defaults for transactions/services; authorization objects/field values are stored in role-related tables such as AGR_1251; AGR_USERS stores assignments. Generated profiles reach user buffers after comparison/logon. GRC/IAM may provision PFCG role assignments while role design remains in ABAP security governance.

A 'Plant Maintenance Planner' role is identical in ten plants except WERKS. The team builds a master role and derived plant roles with organization values. A composite 'Maintenance Planner Job' might bundle the planner role with common display roles. If one plant later needs extra transaction/functions unrelated to org value, that difference should be governed carefully rather than casually breaking the derived design.

PFCG remains important in S/4HANA backend security, while Fiori adds catalogs/spaces/pages and OData/service permissions. Business roles in S/4HANA Cloud have a different administration model, so do not project on-premise PFCG mechanics onto public cloud. Private/on-premise Fiori often maps launchpad content into PFCG roles.

Security role designers own architecture; business process owners approve job-function scope; IAM/GRC provisions assignments; Basis/security admins run generation/comparison; audit reviews segregation/least privilege.

PFCG, AGR_1251 and AGR_USERS pages provide technical details. SU24 defaults and SU53/STAUTHTRACE troubleshooting explain how roles translate into runtime checks.

Production verification: Capture the actual backend user, client and system, failing action, authorization object and field values, assigned roles and validity, trace timestamp, and whether execution was dialog, RFC, background, or propagated from Fiori or BTP. Reproduce under the real identity and correct the least-privilege role rather than testing with SAP_ALL.

Operational readiness: For production readiness of PFCG Roles: Single, Composite and Derived Roles, test with a representative least-privilege business user and with the actual technical or propagated identity used by integrations. Record both allowed and denied scenarios so the role design proves separation of duties rather than merely eliminating errors. Any change that broadens access should identify the business owner and authorization-field scope, and the post-change test should use trace evidence rather than relying only on successful screen navigation.

Review checkpoint: Review checkpoint for PFCG Roles: Single, Composite and Derived Roles: validate the design with at least two users whose organizational scope differs, then capture trace evidence for an allowed and denied operation. Confirm role validity dates, generated profile or user comparison state where applicable, and the actual backend identity used by Fiori, RFC or BTP calls. The production runbook should say which team approves broader access, which authorization fields are business-sensitive, and how emergency access is separated from permanent role design. This turns a one-off authorization fix into a repeatable least-privilege control.