SAP Fiori Roles

• Frontend content: references Fiori catalogs (available apps) and groups/spaces (arranged tiles).
• Backend authorization: grants the authorization objects the app’s OData service checks.

The reason for the split is worth understanding rather than memorising. The launchpad and the application data live in different layers, sometimes in different systems where a hub deployment is used, so entitlement to see an app and permission to read what it displays are genuinely separate questions. In an embedded deployment they happen to sit in one system and they remain two different checks.

A user needs the app on their launchpad (frontend) AND the authorization to run its backend service (backend). If either is missing, they either do not see the tile or get an authorization error when opening it. In hub deployments, this often spans frontend and backend roles that must align.

Because the two halves fail differently, the symptom tells you which one to look at, and that saves most of the diagnosis.

Front end missing, back end present. The user has no tile and cannot find the app in search. If somebody gives them a direct link, it works. The access exists; the entitlement to see it does not.

Front end present, back end missing. The tile is there. Clicking it opens the app, and the app shows an error, or an empty list where data should be. This is the confusing one, because it looks like the app is broken rather than like an authorisation problem.

Service not activated. The tile opens and the app fails to load its data with a message about the service, which is neither half of the role.

Tile with no target mapping. Clicking does nothing at all.

So the question to ask first is whether the user can see the tile, and then whether the app opens. Those two answers narrow it to one of four causes before anybody opens PFCG.

SAP delivers standard business roles for S/4HANA that bundle the right catalogs, groups and authorizations for common jobs (e.g. Accounts Payable Accountant). These are the recommended starting point, copy and adjust rather than building from scratch.

Using a delivered business role as a starting point is nearly always right, and it is a starting point rather than an answer. They are generous by design, covering everything somebody in that role might do anywhere, so the work is trimming rather than building. Copying into the customer namespace first is what makes that safe, because the delivered role will be overwritten by the next upgrade.

Half an hour, and it teaches the two-halves idea faster than any explanation.

1. Take a test user with a working Fiori app: tile visible, app opens, data appears.
2. Remove the back end authorisation for the underlying data, leaving the catalog in place. Log in again. The tile is there; the app opens; the data is missing or an error appears.
3. Put it back, then remove the catalog from the role instead. Log in again. No tile, and search finds nothing.
4. Give the user the direct URL for the app while the catalog is still missing. Note what happens, and whether the back end authorisation alone is enough to see data.
5. Restore both, and confirm normal behaviour.

Doing this once means never again confusing "cannot see it" with "cannot use it".

As always, design roles for least privilege, and keep frontend and backend authorizations consistent, so users get exactly the apps and data their job needs.

The design decision underneath is whether the two halves live in one role or two. One combined role per job is simpler to assign and keeps the halves in step, which is the strongest argument for it. Separate front end and back end roles allow a user to be given back end access without launchpad content, which is occasionally wanted and mostly a source of the mismatch above. Most designs land on combined. See SAP roles for the authorisation mechanics underneath.

The sequence matters because each step depends on the previous one, and doing it out of order produces roles that look complete and do not work.

1. Identify the apps the job needs, from the app library, and note each one's required back end and front end content.
2. Copy the delivered business role into the customer namespace if a suitable one exists, rather than starting empty or editing the original.
3. Trim the front end content to the catalogs and groups or spaces that match the apps you actually want.
4. Maintain the back end authorisations, filling organisational levels for this job's scope: which company codes, plants, sales areas.
5. Generate the profile. Skipping this leaves the changes inert.
6. Activate the OData services the apps need, if they are not already.
7. Test with a user holding only this role, running the job's real tasks.

Step seven is the one that gets dropped under time pressure, and it is the only step that proves any of the others were done correctly.

One role for one job is manageable. An organisation with two hundred jobs across twenty sites needs a structure, or role maintenance becomes the whole job.

Derived roles are the main mechanism. A parent holds the apps and the authorisations; children vary only the organisational values. Twenty sites become twenty derived roles generated from one design, and a change to the parent pushes down.

Composite roles group singles into a job. A person is assigned one composite rather than nine singles, and the composite is what the business can reason about.

A role catalogue maps job titles to roles, which is what makes provisioning repeatable and stops new starters being set up by copying a colleague.

Naming conventions matter more than they should. A role name that encodes the module, the job and the organisational scope lets somebody understand an assignment without opening it.

The failure without this structure is predictable: roles proliferate, several do almost the same thing, nobody can say which to assign, and an access review becomes impossible because the answer to what a role permits requires reading it.

• Frontend app without backend authorization (or vice versa).
• Building roles from scratch instead of adapting SAP business roles.
• Misaligned frontend/backend roles in hub setups.

• Testing a role as somebody who also holds wider access. It proves nothing; test with a user holding only that role.
• Editing the delivered business role rather than a copy. The next upgrade overwrites it.
• Assuming a missing tile is a security problem. See Fiori catalogs, the Fiori architecture and job roles for the surrounding pieces.

• Front end and back end roles maintained by different people with no coordination. They drift, and every drift is a user who can see something they cannot use.

Assigning a role is straightforward, and designing front end and back end together so a job gets exactly the apps and the data it needs is the part you do in the course.

The question that resolves most Fiori access problems in seconds is whether the user can see the tile. Cannot see it is front end; can see it and the app fails is back end. Two different teams, two different fixes.