SAP Authorization Role Design Basics: Single, Composite, and Derived Roles

Good SAP role design gives each user the access required for assigned work without combining unrelated business privileges. The design should begin with business responsibilities, continue through authorization objects and organizational values, and end with testing and periodic review.

This approach works across SAP GUI and application-specific access models. Keep business ownership, technical administration, and approval responsibilities separate so that role changes remain traceable.

01Start with business activities

List the activities a position performs before creating a role. Examples include entering a purchase order, approving an invoice, maintaining a material, posting a journal entry, or displaying a production order. Each activity should have an identified business owner and a defined scope.

Group activities that are performed together by the same users. Keep activities with different risk levels or approval responsibilities separate, even when the same department performs them. A role should represent a stable job responsibility rather than a collection of convenient transaction codes.

A useful design record includes the business process, job function, permitted actions, organizational scope, owner, approver, and review frequency. This record provides the baseline for access testing and later cleanup.

02Understand authorization objects

An authorization object groups related authorization fields that the system checks together. The object determines the type of activity, while its field values determine where or for which organizational area the activity is permitted.

For example, a purchasing activity may require a specific action value and purchasing organization, purchasing group, plant, or company code values. The exact fields depend on the application and the business process. Review the authorization trace and the application’s security documentation when identifying the required objects.

The SAP authorization objects guide provides a focused explanation of how objects, fields, and values work together.

Avoid granting broad organizational values as a shortcut during initial testing. Start with the smallest business scope that supports the process, then expand it when a documented requirement justifies the change.

03Choose single and composite roles

A single role contains the authorization data for a defined set of activities. It is the appropriate building block when the role needs its own authorization values, menu structure, or maintenance lifecycle.

A composite role groups single roles and simplifies assignment to users. It is useful when a job consistently requires several independent role components, such as display access, purchasing access, and reporting access. Authorization values remain maintained in the underlying single roles.

Use single roles for controlled authorization content and composite roles for repeatable user assignment patterns. Do not use a composite role to hide unclear ownership or to combine unrelated privileges without a documented business reason.

04Use derived roles for organizational scope

A derived role is based on a master role and is used when the same activity set applies across different organizational units. The master role defines the common authorization structure, while derived roles carry the organizational values for a plant, company code, sales organization, or other scope.

This model reduces duplicated maintenance. Changes to the common authorization structure can be coordinated from the master role, while each derived role retains its assigned organizational boundaries.

Document the relationship between every master and derived role. Give each derived role a clear naming convention and a business owner who can confirm that its organizational values remain accurate.

05Build roles in a controlled sequence

Use the following sequence when creating or revising a role:

1. Define the job responsibility and business owner.
2. List the required transactions, applications, or launch points.
3. Identify the authorization objects checked by each activity.
4. Set the narrowest practical field and organizational values.
5. Generate the authorization profile in the role maintenance tool.
6. Assign the role to a test user or test business user.
7. Test successful actions and prohibited actions.
8. Record the result, approver, and transport or deployment reference.
9. Assign the approved role to production users through the established access process.

A transaction list is an input to design, not a complete authorization model. The SAP transaction code list can help identify entry points, while the authorization trace confirms what the application actually checks.

06Test both access paths

Test the role with a realistic business scenario and with boundary cases. A successful test confirms that the intended task works; a negative test confirms that the user cannot perform a nearby task outside the approved scope.

Include organizational boundaries in testing. For example, test the permitted plant or company code and then test a different value. Check display, create, change, and approval actions separately because they can require different authorization values.

When a user reports an authorization error, capture the user, action, timestamp, business document, and error details. Use the authorization trace to identify the missing object or field value, then assess whether the role should change or whether the requested action falls outside the user’s responsibility.

07Separate assignment from design

Role design and user assignment are related but distinct controls. The role defines access; the assignment process determines who receives it and for how long.

Use SAP user and role management to align user categories and assignment practices with the role model. Apply time limits or workflow approval where temporary access is required, and remove access when the business responsibility ends.

Review composite-role membership and direct single-role assignments together. A user may receive the same privilege through more than one path, so reviewing only one assignment type can leave excess access in place.

08Review role quality regularly

A role review should confirm that the business purpose still exists, the owner is current, organizational values remain valid, and the assigned users still perform the related work. Review unused transactions, broad organizational values, duplicate roles, and roles with no active owner.

Track changes to authorization values separately from changes to role menus. A menu change may affect navigation, while an authorization-value change can expand access to additional business data or actions.

For environments using single sign-on, the authentication path does not replace authorization design. The SAP single sign-on concept guide explains the relationship between login authentication and the authorizations evaluated after login.

09Troubleshoot overbroad or missing access

Start with the exact business action that failed or exposed excess access. Identify the user’s effective roles, the application entry point, the authorization object, and the relevant field values before changing anything.

For missing access, compare the failed action with a working test case and inspect the trace results. For overbroad access, identify the role and field value that permits the action, then determine whether the value should be narrowed or the role should be split.

Do not solve every error by adding a broad role. A targeted change preserves the original design intent and makes later reviews easier. Record the reason for the change and obtain approval from the responsible business owner.

10Operational checklist

Before releasing a role, confirm the following:

• The role has a defined business purpose and owner.
• The activity scope matches one stable responsibility.
• Authorization objects and organizational values were reviewed.
• Single, composite, or derived structure was selected deliberately.
• Positive and negative tests were completed.
• User assignment has an approval record.
• The role has a review date and retirement condition.
• Changes are traceable through the normal transport or deployment process.

A role model is healthy when users can complete their work predictably, business owners understand what access they approve, and administrators can explain every significant authorization value.