If SU01 is the HR file, PFCG is the job description. It's where you define what a user is allowed to do, and it's the transaction SAP security consultants spend most of their lives in. Roles are the single most important concept in SAP authorization management, so it's worth understanding exactly how they're built.
The hierarchy: user → role → profile → authorization
Authorizations in SAP work in layers, and mixing them up causes endless confusion. At the top sits the user (SU01). Users don't hold authorizations directly — they hold roles. A role is a bundle of permissions for one job function: "Accounts Payable Clerk," "Warehouse Supervisor," that sort of thing.
Inside a role, the menu (the transactions and apps you've added) generates authorization data. When you generate the role, the system compiles that data into a profile — a technical container the kernel actually checks at runtime. And inside the profile are individual authorizations: instances of authorization objects with specific field values, like "company code 1000, activity 03 (display)" for object F_BKPF_BUK.
So the chain is: user gets roles, roles generate profiles, profiles contain authorizations, authorizations are checked against objects. You maintain roles in PFCG; everything below that is generated.
Key takeaway: Never assign authorizations directly to users. Always go through roles — it's the only structure that stays maintainable and auditable as the system grows.
Building a role, step by step
Create the role in PFCG and give it a sensible name — most companies use a naming convention with a prefix per module or company code, because a thousand roles named "TEST_ROLE_1" through "TEST_ROLE_999" is a special kind of pain.
On the Menu tab, add the transactions, reports, and (in S/4HANA) Fiori apps the job needs. This is deliberately the first step: the menu drives which authorization objects the system proposes on the next tab, so a complete menu saves you manual work later.
On the Authorizations tab, click the "Change authorization data" button. PFCG proposes the authorization objects for everything in your menu. Now comes the real work: maintaining the field values. Each object shows a traffic light. Red means unmaintained — the role won't generate until you fix these. Yellow means you changed SAP's proposed standard values. Green means maintained and ready. Work through the reds, setting organizational levels (company code, plant, purchasing org) and activities (create, change, display) to exactly what the job needs — no more.
Then click Generate (the red-and-white icon). This compiles the profile. Finally, go to the User tab, assign the users, and run a user comparison so the new profile lands in their user masters.
Single, composite, and derived roles
A single role is the basic building block: one menu, one set of authorizations, one generated profile. Most roles should be single roles.
A composite role is a container that bundles several single roles together. You'd use one for a job that genuinely spans functions — say a plant manager who needs the production supervisor role plus the maintenance planner role. Assigning the composite to the user is cleaner than assigning five singles, and when the job changes you update the composite once.
Derived roles solve a different problem: the same job in different organizational units. You build a parent role for "AP Clerk" with company code left open, then derive children for company code 1000, 2000, 3000. The menu and most authorizations inherit from the parent; only the org-level fields differ. Change the parent's menu and the change flows down — much better than maintaining three near-identical roles by hand.
What usually goes wrong
The number one sin is the over-authorized role: someone couldn't be bothered to maintain the red traffic lights properly, so they set everything to * (full authorization) to make the errors go away. The role works, the ticket closes, and six months later the auditor asks why every AP clerk can post in every company code. Maintain the values properly the first time — it's slower, but it's the entire point of the exercise.
The second is role sprawl: hundreds of one-off roles created for individual users instead of a clean set of job-based roles. If your role count is approaching your user count, the design has failed. Step back, define the actual jobs in the business, and rebuild.
PFCG rewards patience. A well-designed role catalog — single roles per job, composites for combined jobs, derived roles for org splits — is the difference between security you can manage and security you merely hope is working.