PFCG — PFCG Role Maintenance Transaction

PFCG builds authorization roles. A role has a menu of transactions, Fiori apps, or reports, an Authorizations tab where objects and field values are maintained, and a User tab where the role is assigned to individual users with a validity period. The structural fact that explains most confusion: these are three independent steps with three independent saves. Changing the menu does not touch the authorization data. Changing the authorization data does not update the generated profile until it is explicitly generated. Generating the profile does not push it into a user's session until a user comparison is run. A role can look complete and correct on screen while the actual runtime authorization a user carries is several steps out of date.

PFCG is reached for whenever access needs to be granted, changed, or removed at the role level, which is the normal path in any environment with a segregation-of-duties model. Security consultants use it during initial role build, during change requests that add a transaction or Fiori app to an existing role, during remediation of SoD conflicts, and during role redesign projects. It is not used for one-off user changes to lock, unlock, or reset a password, or to assign an existing role to a single user quickly, both of which sit more naturally in SU01. It is not used to analyze who already has what, which is SUIM's job. It reads its proposed authorization values from SU24, so any change to what a transaction should require by default is made there, not in PFCG.

To confirm whether a user actually has a role, query AGR_USERS filtering on the user ID and role name and check the validity dates against the current date; an expired 'to' date means the assignment is dead even though it still shows in PFCG history. To confirm what values a role actually carries, query AGR_1251 filtering on the role name and the authorization object in question. If the user's actual authorization does not match what AGR_1251 shows, the profile was not regenerated or not compared, which points at the generation step rather than the data itself.

PFCG is unchanged as the role-build transaction on S/4HANA. What changes is the content of the role menu, which now carries Fiori business catalogs, spaces, and app tile references alongside or instead of classic transaction codes. Building a role that grants a Fiori app correctly requires assigning the right catalog and space in addition to the backend authorization object for the underlying OData service, which is an additional step that has no ECC equivalent. There is no Fiori app that replaces PFCG itself for on-premise or private cloud role administration.

This is a security/GRC functional problem, not an ABAP development problem, though it sits close to Basis because profile generation and user buffer behavior are technical. A good handover includes the role name, the exact transaction or app requested, the business justification and org values approved, the affected user ID, and if troubleshooting a denial, an ST01 or SU53 trace showing the failing object.

SU24 controls what PFCG proposes by default and is the right place to fix systematic gaps rather than patching individual roles. SU01 is where a single user's role assignment or lock status is checked when a PFCG change does not explain the symptom. SU10 is used to push a role change or comparison across many users at once instead of one at a time. SUIM answers who currently holds a role or an authorization object, which is the starting point before deciding what to change in PFCG. ST01 or its successor trace tool is used to capture the exact authorization check that failed at runtime, which turns a vague access complaint into a specific object and value to fix on the Authorizations tab.