Hamburger Skyline - Hupp Consulting SAP Beratung
Hupp Consulting Logo
Hupp Consulting

SAP Role Design: Best Practices for Clean Authorisation Architecture

The role concept is the foundation of every SAP authorisation system. A clean design saves enormous maintenance effort in the long run, reduces SoD conflicts and simplifies audits. In practice, however, many role concepts have grown over years without clear structure. This article describes best practices for sustainable role design.

Understanding and Using Role Types Correctly

SAP offers three role types: single roles contain the actual authorisations and are the basis of every concept. Composite roles bundle multiple single roles into a business function – e.g. “Buyer” as a combination of purchase order creation, vendor reporting and report roles. Derived roles inherit the menu and authorisation objects from a master role but allow different organisational levels – ideal for organisations with multiple company codes or plants.

Naming Conventions That Scale

A consistent naming convention is essential. Proven pattern: Z_[Module]_[Function]_[Type]. Example: Z_MM_PO_CREATE_SR (single role for PO creation in MM). Use suffixes for role types: SR for single role, CR for composite role, DR for derived role. Limit role names to 30 characters and use only uppercase letters and underscores.

Document the naming convention and make it binding. Every exception dilutes the system.

Granularity: Finding the Right Balance

A common mistake is wrong granularity: overly broad roles (one role per department) lead to excessive authorisations and SoD conflicts. Overly fine roles (one role per transaction) create enormous administrative effort with hundreds of role assignments per user.

Optimal granularity follows business functions: a role should contain the authorisations for a coherent activity – e.g. “create and edit purchase requisition” rather than “call ME51N”. In practice, this typically means 200–500 single roles for a mid-sized organisation.

Using Organisational Levels Correctly

Organisational levels (org levels) such as company code, plant or purchasing organisation are the most powerful tool for scaling the role concept. Instead of creating a separate role for each company code, define a master role and derive roles for each company code. The derived roles inherit all authorisation objects and menus; only the org level values differ.

Role Design for S/4HANA and Fiori

With S/4HANA and Fiori, role design changes: in addition to classic backend authorisations, users need Fiori catalogues and groups, OData service authorisations (S_SERVICE) and frontend roles for the Fiori Launchpad. Plan these additional layers from the start. SAP delivers predefined business roles that can serve as a starting point.

Avoiding Common Mistakes

The most common role design mistakes:

  • SAP_ALL as a solution: Never use SAP_ALL or similarly broad profiles in production
  • Copied roles without adjustment: Copying roles from other users leads to authorisation accumulation
  • Missing documentation: Every role should have a meaningful long text describing the business function
  • No test workflow: Taking roles to production without structured testing
  • Missing governance: No defined process for role creation, modification and deletion

Lifecycle Management and Governance

Define clear processes for the entire role lifecycle: request (who may request new roles?), design and creation (following defined standards), test (SU53 analysis, functional test, SoD check), approval (dual control principle), transport (controlled via TMS) and regular review (are the roles still current?). Tools such as SAP GRC Access Control Business Role Management (BRM) support this process but are not a prerequisite.

Conclusion

A clean role concept is an investment that quickly pays off – through less maintenance effort, fewer SoD conflicts and smoother audits. Start with clear naming conventions and the right granularity. For existing systems, a gradual cleanup alongside daily business is recommended.

Get in touch →

Stefan Hupp
Managing Director

20+ years of experience in SAP Security, Basis and Authorisations. Pragmatic solutions for complex system landscapes – documented, audit-ready and AI-powered.

Related Articles

Authorisations

March 2026 · Stefan Hupp

SoD Conflicts in SAP: Detection, Assessment & Resolution

Systematically detect, assess and pragmatically resolve SoD conflicts.

Read more →
Authorisations

March 2026 · Stefan Hupp

Fiori Authorisations in S/4HANA: Concept, Catalogues & Troubleshooting

Understand Fiori authorisations: Launchpad catalogues, OData services and troubleshooting.

Read more →
Authorisations

January 2026 · Stefan Hupp

Cleaning Up SAP Authorisations: A Pragmatic Guide

A step-by-step approach to bringing order to legacy authorisations.

Read more →

Need support with this topic?

We help you with implementation – from analysis to go-live.

Get in touch

← All articles