PFCG is the transaction for role maintenance in SAP — the central tool for building, changing, and managing authorization roles. Every SAP user gets their permissions through roles, and roles are built in PFCG. Whether you are a Basis administrator, a security consultant, or a developer who needs to understand why a user gets an “authorization missing” error, this guide walks you through PFCG role administration step by step.
What Is PFCG?
PFCG (Profile Generator) is the transaction used to create and maintain roles in SAP systems. A role bundles together menu entries (transactions, reports, links) and authorizations (what the user is allowed to do with those entries). When a role is generated, PFCG creates an authorization profile; assigning the role to a user (via SU01) gives the user the authorizations in that profile.
In short: menus define what users see, authorizations define what users may do, and PFCG is where both are assembled into roles.
Role Types: Single, Composite, and Derived
Before creating roles, understand the three role types:
- Single roles contain one menu and one set of authorizations. They are the building blocks — for example, “Accounts Payable Clerk” with the specific transactions and authorization values an AP clerk needs.
- Composite roles (also called collective roles) are containers that group multiple single roles together. A “Finance Power User” composite role might include the AP clerk, AR clerk, and GL accountant single roles. Composites simplify assignment: assign one composite instead of many singles.
- Derived roles inherit the menu and authorizations of a parent single role but allow different organizational-level values. For example, a parent role “Plant Maintenance Technician” can be derived into “Plant Maintenance Technician — Plant 1000” and “Plant Maintenance Technician — Plant 2000,” each restricted to its own plant. Derived roles reduce duplication: change the parent, and the menu structure flows to the children.
Step 1: Create the Role and Maintain the Menu Tab
- Execute transaction PFCG.
- Enter a role name following your naming convention (for example, Z_MM_PURCHASER) and click Create (single role).
- On the Description tab, enter a meaningful description of the role’s purpose.
- Go to the Menu tab. Here you build what the user sees: add transactions (by TCode), reports, URLs, or menu folders. For a purchaser role, you might add the purchasing transactions and relevant reports.
- Save the role.
The menu tab is the visible face of the role — it determines the user’s SAP Easy Access menu entries.
Step 2: Maintain Authorizations on the Authorizations Tab
- Switch to the Authorizations tab and click “Change Authorization Data.”
- PFCG proposes an authorization profile based on the menu entries: for each transaction in the menu, it suggests the authorization objects the transaction checks, with default field values.
- Work through the object list. The most fundamental object is S_TCODE, which controls which transaction codes a user may start — its field TCD holds the allowed TCodes.
- For each authorization object, maintain the field values to match the job requirements: which company codes, plants, document types, or activity levels (create, change, display) the role permits.
- Set the profile status and generate the profile (the “Generate” step creates the actual authorization profile from your maintained values).
This is the heart of role administration. Take time here: overly broad values create security risk, while overly narrow values generate support tickets from users who cannot do their jobs.
Step 3: Assign Users on the User Tab
- Go to the User tab in PFCG.
- Enter the user IDs that should receive the role and save.
- Run User Comparison (the user master comparison) so the generated profile is actually written into the users’ master records. Until the comparison runs, the assignment has no effect.
User assignment can also be done from the other direction: transaction SU01 (User Maintenance) lets you assign roles to a single user on the Roles tab. Both paths end with the profile in the user master record.
Understanding Authorization Objects
Authorization objects are the grammar of SAP security. Each object has fields, and a user’s authorizations are field-value combinations. Key concepts:
- S_TCODE: controls transaction start authorization (field TCD = transaction code).
- Authorization checks happen in ABAP code via the AUTHORITY-CHECK statement — if the user lacks the required field values, the system raises an authorization error.
- When a user reports “no authorization,” transaction SU53 displays the last failed authorization check, showing exactly which object and field value was missing. This is the fastest diagnostic tool in authorization troubleshooting.
You do not need to memorize hundreds of objects to start: understand the object-field-value model, learn S_TCODE, and expand from there as you maintain real roles.
Step 4: Transport the Role
Roles are transportable objects. After creating and generating the role in the development system:
- In PFCG, choose the transport option for the role.
- Add it to a transport request (via SE09/SE10).
- Release and import through the landscape like any other customizing or workbench object.
Always test the role with a test user in the quality system before importing to production.
Using SUIM for Role Reporting
SUIM (User Information System) is the reporting companion to PFCG. Use it to answer questions like:
- Which users have a particular role?
- Which roles contain a specific transaction or authorization object?
- What does a user’s complete authorization footprint look like?
- Where is a specific authorization value used across roles?
Regular SUIM reviews — for example, listing users with critical authorizations — are a cornerstone of SAP security audits and Segregation of Duties (SoD) analysis.
Best Practices for Role Administration
- Least privilege: grant only the authorizations the job genuinely requires. Start narrow and expand based on justified requests.
- Naming conventions: use a clear, consistent scheme (for example, Z_<module>_<function>) so roles are discoverable in SUIM and transports.
- Prefer derived roles over copying single roles when only organizational levels differ — it keeps maintenance centralized.
- Document the role’s purpose in the description tab; future administrators will thank you.
- Never assign SAP_ALL broadly in production; it grants unrestricted access and defeats the entire authorization concept.
- Review periodically: run SUIM reports on a schedule to find dormant users, overly broad roles, and SoD conflicts.
- Test as the user: after generating and assigning, log on as a test user (or use proper test procedures) to verify the role works before handing it over.
Troubleshooting Common PFCG Issues
Even well-built roles run into problems. Here are the issues administrators see most often and how to resolve them:
- “No authorization” after assigning a role: the most common cause is a missing user comparison. Go to the User tab in PFCG and run the comparison so the profile lands in the user master record. Then have the user log off and back on.
- SU53 shows a missing object not in the role: add the authorization object (or the missing field value) on the Authorizations tab, regenerate the profile, and re-run user comparison.
- Role works in development but not in quality: the transport may not have included the generated profile, or the role was changed after transport. Re-transport the role and verify in SUIM that the target system has the current version.
- Menu entries missing for the user: check that the transactions were actually added on the Menu tab and that S_TCODE contains them. A transaction in the menu without S_TCODE authorization will not start.
- Too many “missing authorization” tickets: usually a sign the role was built too narrowly, or that it was copied from a template without adjusting organizational levels. Review the role against the actual job description rather than adding authorizations one ticket at a time.
A disciplined loop — reproduce, check SU53, adjust in PFCG, regenerate, compare users, retest — resolves the vast majority of authorization incidents.
Segregation of Duties: Why Roles Matter Beyond Access
Roles are not just about letting people work; they are about preventing fraud. Segregation of Duties (SoD) means no single user should hold combinations of authorizations that enable abuse — the classic example is a user who can both create a vendor and post payments to that vendor. Well-designed single roles make SoD analysis possible: auditors review which sensitive combinations exist across roles and flag conflicts. Keep SoD in mind when building roles, and document any approved exceptions.
Frequently Asked Questions
What is PFCG used for in SAP?
Answer: PFCG is the role maintenance transaction. Administrators use it to create roles, build menus, maintain authorization data, generate profiles, and assign roles to users.
What is the difference between a single role and a composite role?
Answer: A single role holds one menu and one authorization set. A composite role groups multiple single roles into one assignable unit, simplifying user administration.
What is user comparison in PFCG and why does it matter?
Answer: User comparison writes the generated authorization profile into the assigned users’ master records. Without it, assigning a role in PFCG has no effect on what the user can actually do.
How do I find which authorization a user is missing?
Answer: Execute SU53 immediately after the failed check (as the affected user, or have them run it). It shows the authorization object, field, and value that caused the denial.
Can I copy an existing role in PFCG?
Answer: Yes — copying a role (for example, to create a derived role or a variant) is standard practice and faster than building from scratch. Always review the copied authorization values before generating.
Where can I learn more about the users behind the roles?
Answer: Role administration pairs naturally with user maintenance: SU01 manages the user master record where roles land. For the data model that roles ultimately protect, see our SAP MM tables reference.