This is how companies build a secure, maintainable, and license-compliant authorization concept in SAP Cloud ERP Public using Business Roles, Business Catalogs, and Restrictions.
Introduction
An authorization concept in SAP S/4HANA Cloud Public Edition must be structured differently than in traditional SAP landscapes. In SAP Cloud ERP Public, the focus is not on individual transactions or freely modeled authorization objects, but on a standardized model consisting of Business Users, Business Roles, Business Catalogs, and Restrictions.
This is exactly where the real challenge often lies in projects. Many companies still transfer the logic from SAP S/4HANA Private Cloud or on-premise environments into the Public Cloud. This leads to custom roles, unnecessary complexity, and a role model that is neither easy to govern nor aligned cleanly with the PUPM licensing logic.
From the perspective of Fink IT-Solutions, the authorization concept in SAP Cloud ERP Public is therefore not a side issue. It is a central building block for security, governance, operational stability, and economically transparent usage.
Table of Contents
- What is an authorization concept in SAP S/4HANA Cloud Public Edition?
- How does the authorization model work in SAP Cloud ERP Public?
- Which objects are central to the authorization concept in SAP Cloud ERP Public?
- What is the difference between Public Cloud and Private Cloud in the authorization concept?
- Why are Restrictions so important in the authorization concept of SAP Cloud ERP Public?
- How are PUPM and the authorization concept connected in SAP Cloud ERP Public?
- Which mistakes commonly occur in the authorization concept of SAP S/4HANA Cloud Public Edition?
- How does Fink IT-Solutions build an authorization concept for SAP Cloud ERP Public in practice?
- Conclusion
- FAQ
What is an authorization concept in SAP S/4HANA Cloud Public Edition?
An authorization concept in SAP S/4HANA Cloud Public Edition defines which users in SAP Cloud ERP Public are allowed to perform which tasks, through which roles these accesses are controlled, and how organizational restrictions, governance, and licensing logic are brought together.
A robust authorization concept includes at least:
- a functional role model
- the assignment of Business Roles
- the use of suitable Business Catalogs
- a clean Restriction Design
- the separation of end-user, key-user, and administration roles
- governance for request, approval, and recertification
- a transparent connection to the PUPM logic (Per User Per Month licensing logic)
The key question is therefore not: Which individual authorization does a user need?
But rather: Which functional persona needs which role in which organizational context?
How does the authorization model work in SAP Cloud ERP Public?
The authorization model in SAP Cloud ERP Public follows a clear logic:
Business User → Business Role → Business Catalogs → Apps & Authorizations
This means:
In SAP S/4HANA Cloud Public Edition, a user does not receive direct access to individual transactions. Instead, functional access is controlled through Business Roles. These roles contain Business Catalogs, and the catalogs bundle the required apps and authorizations.
This is crucial in practice. A good authorization concept in SAP Cloud ERP Public is not designed from isolated exceptions, but from recurring role patterns.
Typical examples are:
- accounts payable accountant
- accounts receivable accountant
- operational purchaser
- head of purchasing
- project controller
- Key User Finance
- IAM Administrator
From FINK-IT’s point of view, the following applies:
The clearer the persona, the cleaner the role model.
Which objects are central to the authorization concept in SAP Cloud ERP Public?
Business User
The Business User is the specific end user or technical user who requires access to the system.
What is important here:
Access is not assigned directly, but through roles. This is exactly what makes the model in SAP Cloud ERP Public scalable and release-capable.
Business Role
The Business Role is the central control object in the authorization concept of SAP S/4HANA Cloud Public Edition. It defines which tasks a user is functionally allowed to perform.
A good role model is based on stable tasks and not on individuals, one-off requests, or historically grown exceptions.
Business Catalog
Business Catalogs contain the functionally required apps and authorizations. They are the technical link between the role and the actual access.
Restrictions
Restrictions limit roles to specific organizational and data areas. Only then does a general functional role become a securely usable productive role.
Typical restriction fields are:
- company code
- plant
- purchasing organization
- sales organization
- controlling area
What is the difference between Public Cloud and Private Cloud in the authorization concept?
The difference between SAP S/4HANA Cloud Public Edition and SAP S/4HANA Private Cloud is significant in the authorization concept.
Authorization concept in SAP Cloud ERP Public
In SAP Cloud ERP Public, the model is more strongly standardized. At the center are:
- Business Roles
- Business Catalogs
- Restrictions
- role-based instead of individual assignment
- high maintainability and release readiness
Authorization concept in SAP S/4HANA Private Cloud
In the Private Cloud or classic S/4HANA, the authorization model is generally more flexible, more technical, and closer to traditional SAP logic. Companies have more freedom in role design there, but also more complexity in maintenance.
What this means in practice
Anyone building an authorization concept for SAP Cloud ERP Public using Private Cloud logic often creates exactly the problems that become expensive later:
- too many custom roles
- lack of standardization
- unclear governance
- poor scalability
- high maintenance effort
- no clean interaction with PUPM
Based on our project experience, one thing is clear:
Public Cloud needs a target role model with cloud logic, not with on-premise thinking.
Why are Restrictions so important in the authorization concept of SAP Cloud ERP Public?
In many projects, a lot of discussion initially revolves around role names and role descriptions. But the real quality lever almost always lies elsewhere: in the Restrictions.
Even a functionally correct role is problematic if it is too broadly defined organizationally. This is exactly how excessive authorizations arise.
A clean restriction design answers questions such as:
- For which company codes is the role valid?
- In which plants is the user allowed to work?
- Which purchasing organizations are approved?
- At which organizational levels is separation required?
- At which points is separation mandatory from a compliance perspective?
From the perspective of Fink IT-Solutions, this is one of the most common weaknesses in projects.
The problem is usually not the role name, but the missing organizational restriction.
How are PUPM and the authorization concept connected in SAP Cloud ERP Public?
The connection between PUPM and the authorization concept in SAP S/4HANA Cloud Public Edition is strategically important.
PUPM stands for a user-based licensing model. Therefore, the authorization concept should not be developed separately from the licensing logic. It is not only about who can technically access something. It is also about ensuring that roles, usage, and user profiles fit together cleanly.
The derivation is simple
1. Roles control actual usage
What a user can do in SAP Cloud ERP Public depends directly on their roles, catalogs, and restrictions.
2. Overly broad roles distort the usage profile
If users receive functions they do not need for their job, this not only creates a security problem. It also results in an unclear usage model that is difficult to explain organizationally.
3. PUPM needs clear personas
For the user-based licensing logic to work properly, roles must be cut along real user profiles, for example:
- clerk
- approver
- key user
- administrator
- process owner
4. Authorization concept and PUPM must be considered together
A good authorization concept in SAP Cloud ERP Public helps to
- clearly separate user groups
- assign roles transparently
- reduce custom roles
- clearly describe usage profiles
- combine governance and economic efficiency
This is the decisive point from Fink-IT’s perspective:
A cleanly designed role model creates not only security, but also transparency in the user-based licensing logic.
Which mistakes commonly occur in the authorization concept of SAP S/4HANA Cloud Public Edition?
In projects, we keep seeing the same patterns:
- standard roles are adopted almost unchanged
- roles are designed according to people instead of tasks
- restrictions are missing or too broad
- operational and administrative roles are mixed
- governance processes are defined too late
- release reviews are not planned
- PUPM and the authorization concept are considered separately
The last weakness in particular is relevant in SAP Cloud ERP Public. If the role model and licensing logic are not considered together, ambiguities arise in usage, responsibility, and economic efficiency.
How does Fink IT-Solutions build an authorization concept for SAP Cloud ERP Public in practice?
In our experience, an authorization concept for SAP S/4HANA Cloud Public Edition works particularly well when it is built in five clear steps.
1. Create a functional role matrix
First, we define the relevant personas, tasks, and responsibilities together with the business departments.
2. Precisely tailor Business Roles and Catalogs
Then it is determined which functional content and which roles are truly required for each persona.
3. Systematically design Restrictions
In the next step, company codes, plants, purchasing organizations, and other organizational characteristics are mapped cleanly to roles and responsibilities.
4. Connect governance and PUPM logic
Then approvals, recertifications, separation of roles, exceptional access, and the user-based licensing logic are brought together.
5. Test roles and assign them productively
Finally, roles are tested per persona, conflicts are resolved, and users are assigned cleanly in production.
Our project experience shows:
The best authorization concept in SAP Cloud ERP Public emerges where functional requirements, organizational logic, security, and PUPM are considered together.
Conclusion
A robust authorization concept in SAP S/4HANA Cloud Public Edition does not arise from individual roles, but from a clear improvement concept with a defined target picture. This includes precisely tailored Business Roles, suitable Catalogs, precise Restrictions, clear governance, and a transparent connection to the PUPM logic.
The difference becomes visible in operations: while simple models are often merely documented, a structured improvement concept ensures security, maintainability, and transparency in SAP Cloud ERP Public.
Would you like to optimize or redesign your authorization concept? Fink IT-Solutions supports you with this: Contact form | Fink IT-Solutions – IT Consulting & Solutions in Würzburg – Fink IT-Solutions.
For classification within an overarching target picture and the right cloud strategy, we also recommend our article on the SAP Cloud ERP decision framework.
FAQ
The central control object is the Business Role. It bundles functional tasks, apps, and authorizations for users.
In the Public Cloud, the model is more standardized and aligned with Business Roles, Business Catalogs, and Restrictions. In the Private Cloud and in classic S/4HANA, authorization models are generally more flexible and technically driven.
Because they limit roles to specific organizational and data areas. Without Restrictions, excessive authorizations and unnecessary risks arise quickly.
Usually not. Standard roles are a useful starting point, but in most cases they need to be adapted to the company’s functional requirements, organizational structure, and governance.