SAPFree worksheetPDF, Excel, Word exportSAP ECC and S/4HANA

SAP Role Design Worksheet: Plan PFCG Roles Before You Build Them

Good SAP roles are designed on paper before they are built in PFCG. This worksheet gives you one row per role with its type, business function, org-level restriction, transaction count, sensitive objects and user count, so you can compare roles and spot the risky ones early.

Download:

Role name	Role type	Business function	Key transactions	Org level restricted by	Transaction count	Critical auth objects	Assigned users	Exposure score	Role owner
								50.4
								20.4
								70.4
								44.8
								102.4
								50.4

Total role assignments

Highest exposure score

102.4

Average exposure per role

56.4667

Compare roles against this average to find outliers worth redesigning.

The exposure score is a planning aid: (critical objects x 5 + transactions x 0.2) x assigned users. It is not an SAP value. Adjust the weights to suit your risk policy.

Role clean-up review

Optional: bring a PFCG role export and we can discuss how to analyze it over your own data without sending it outside your network.

Optional. The tool and every export work without this. No spam.

How to use the worksheet

Add a row for every role you plan to build or already run. Fill in the business function in plain language first, then list the key transactions rather than every one. Pick the org level that restricts the role: company code for finance roles, plant or purchasing organization for logistics. Count the sensitive authorization objects the role carries and estimate the assigned users. The exposure score updates automatically. Export to Excel to share with role owners for sign-off. Many teams also add the naming convention they follow, such as Z_<module>_<function>, in the role name column so reviewers can see the pattern at a glance.

One row per role, including composite roles
Record a named business owner for every role
Keep the transaction sample short, hold the full list in PFCG

Single, derived and composite roles

A single role holds menu entries and authorizations built in the PFCG profile generator. A derived role inherits the menu and authorization structure of a parent role and differs only in organizational values, for example the company codes. A composite role is a container of other roles and holds no authorizations of its own. Deriving by org level keeps the number of structurally different roles low, while composite roles group tasks into job positions. The usual design is task-level single or derived roles, assembled into position-level composite roles.

Derive roles to vary only org levels
Use composite roles to match job positions
Do not add authorizations by hand to the composite

Reading the exposure score

The score weights critical authorization objects heavily because a single object like S_TABU_DIS or S_DEVELOP can bypass business controls. It then multiplies by users because the same role assigned to many people spreads the risk. In the sample data the user administration role scores far higher than the large buyer role, even though far fewer people hold it. That is the point: you review the high scorers first, ask whether the critical objects are needed, and consider splitting the role if they are used by only part of the user group.

Review the highest scorers first
Split roles when critical objects serve few users
Revisit scores after each access review

Common mistakes

The most common mistake is copying SAP standard roles such as SAP_ALL-adjacent profiles into custom roles and hoping to trim later. Another is building roles around people rather than tasks, which produces hundreds of one-off roles. Teams also forget to maintain the SU24 proposals, so new transactions silently add authorizations. Finally, roles are rarely retired. Add a status or review date in a spare column and remove unused roles during each access review.

Build from SU24 proposals, not from copies of old roles
Test with a real user and SU53 before go-live
Retire unused roles on a schedule

Frequently Asked Questions

What is the difference between a derived role and a composite role in SAP?

A derived role inherits the menu and authorization structure from a parent role and changes only organizational values, such as company codes. A composite role is a collection of other roles and has no authorizations of its own. Derived roles reduce duplication; composite roles map to job positions.

What naming convention should SAP custom roles follow?

Custom roles must live in the customer namespace, usually starting with Z or Y. Beyond that, a pattern such as Z_<module>_<function>_<type> works well. Consistency matters more than the exact pattern, because it lets auditors and reviewers filter roles by area.

How many transactions should one SAP role contain?

There is no fixed number. Design roles around a coherent task, such as processing supplier invoices, rather than a count. If a role grows past a few dozen transactions or mixes tasks that conflict, it is usually a sign it should be split.

Does the exposure score replace a segregation of duties analysis?

No. It is a quick planning aid that highlights roles with sensitive objects and many users. A segregation of duties analysis checks combinations of access across roles for conflicts. Use the score to prioritize review, then run a proper SoD check.

If your role concept lives in spreadsheets and PFCG exports, Netray can help you ask questions of that data in plain language, with the model running inside your own network.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

Back to All Tools