ical roles, plus two major releases a year that can reshuffle your entire authorization model. That’s how authorization works in SAP Public Cloud — and that’s the topic of the new GRC Ninja episode.

In the previous episode we asked what SAP Public Cloud is, who it suits, and where its limits are. Now we go one level deeper. Rafał, a consultant who has supported several of these implementations, walks through a live system. He shows what a business role is made of, what the user sees in the Launchpad, and why the authorization model needs a review every six months. Here are the main takeaways from that conversation.

PFCG is gone. The business role takes center stage

Public Cloud approaches authorization in a completely different way than on-premise and private cloud systems. Business roles have replaced the classic technical roles built in PFCG. Each role consists of business catalogs, and those consist of Fiori apps. Spaces and Pages define how it all gets presented — these are the navigation spaces and pages in the Launchpad. Restrictions come last; they limit access to data inside the apps themselves.

Sounds logical? On paper, yes. In practice this model surprises even experienced consultants, because a role is more than access — it’s the whole layout of apps in the user interface. You can grant every authorization, but without assigned Spaces and Pages the user logs in to an empty screen. In on-premise that would never fly. Here it’s the norm.

What makes up a role in Maintain Business Roles?

Roles are managed in the Maintain Business Roles app — a repository where you create and modify them. Each role has a few building blocks:

• General data — the role description and access categories, meaning whether the role allows editing data or only displaying it. This is also where you see the role’s pricing category.
• Business Catalogs — the catalogs that give users access to individual apps. You can open each catalog and inspect its details.
• IAM Apps — every app assigned through the catalogs. From here you can also trim access to selected ones.
• Launchpad Spaces — navigation spaces that help employees find the apps they need.
• Restrictions — data filters inside the apps, for example at the level of company code, plant, or authorization group.

The whole model is visual by design. And that’s exactly why it demands discipline: every piece of this puzzle has to land in the right place, or someone loses part of their screen.

Two releases a year. Who decides what changes?

An on-premise environment ran for years, until you decided to upgrade it yourself. In Public Cloud, SAP makes that decision: centrally, twice a year. A major release brings functional changes, new Fiori apps, and sometimes adjustments to catalogs or restrictions. All of it hits authorizations directly.

Take an accountant’s role. After a new release, SAP may add apps to the Accounts Payable catalog, or rename or recategorize an existing app. It may also remove functions that used to be available, or introduce a new field in the restrictions. The accountant suddenly sees a new tile and can run an operation they had no rights to before. Or the opposite: they lose access to a report they’ve worked with for months.

These are not theoretical scenarios. In one project, SAP changed its approach to required values in restrictions and nobody corrected the roles in time. The financial reports looked fine, yet showed only part of the data. In another release, a business catalog disappeared and the administrator never assigned its successor.

Can you keep this under control? Yes — the tools exist. The Manage Changes After Upgrade function in Maintain Business Roles lists the changes that affect a given role, such as deprecated catalogs replaced by new ones. The What’s New Viewer describes changes in business language, often with details on how they affect authorizations and guidance on correcting roles. Each release also comes with a note that gathers every authorization change: in roles, catalogs, restrictions, and related objects. The problem? Hardly anyone reads it.

Four mistakes that keep coming back

1. Roles that are too broad

A classic. During testing, users get wide access “so things work” — and then it stays that way. The result: access to functions nobody needs, more room for mistakes, and higher license costs, because some apps push a user into a higher pricing category. In the worst case, an audit uncovers segregation of duties conflicts nobody had noticed, and suddenly fraud is on the table.

2. Missing Spaces and Pages

Users log in, see an empty screen, and report that the system is down. The roles are formally assigned, so the IT team digs through logs hunting for a technical bug. And it’s simply a missing menu. Rafał has seen projects where testing started a week late because of this.

3. No restriction review after releases

A silent time bomb. After an update, SAP can change restrictions or add new fields, and part of your data disappears from reports. A user stops seeing documents from another company code, because that field got a new value. Sometimes it surfaces only after a week, when someone notices invoices missing from their reports. You cannot skip cloud releases, so a role review after every update has to be a standing process, not a rescue mission.

4. No SoD control

In on-premise, GRC-class systems monitored authorization conflicts. In Public Cloud this often gets forgotten: the system is standard, so the risks feel smaller. Not true. You can still have a user who creates vendors and approves payments — but without an updated rule base for Fiori apps, no tool will show it. Auditors then have a field day: everything works, but nobody can prove it works by the rules.

Maintaining authorizations is a process, not a project

Each of these mistakes carries real consequences: from user frustration, through data errors, to audit and financial risks. The old “build it once and forget it” rule is dead in the cloud. The authorization team works a bit like a security team — tracking releases and reacting to what they bring. Twice a year, SAP deals a new hand. The winners are organizations that set a standard at the start of the project and stick to it.

See it live in the system

This article is based on a GRC Ninja episode about the authorization model in SAP Public Cloud. The video shows a full demo: what a business role looks like in the Maintain Business Roles app, and how Manage Changes After Upgrade works. You’ll also see what to check before every release — before an auditor checks it for you. The whole thing runs just under 11 minutes, perfect for a single coffee. Watch the episode on the GRC Ninja channel and share your own list of mistakes in the comments. Maybe you have one we didn’t mention?