SoD Conflicts in SAP: Detection, Assessment & Resolution
Systematically detect, assess and pragmatically resolve SoD conflicts.
Read more →
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.
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.
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.
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.
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.
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.
The most common role design mistakes:
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.
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.
Systematically detect, assess and pragmatically resolve SoD conflicts.
Read more →Understand Fiori authorisations: Launchpad catalogues, OData services and troubleshooting.
Read more →A step-by-step approach to bringing order to legacy authorisations.
Read more →We help you with implementation – from analysis to go-live.
Get in touch