Lesson 2 of 5
Target role architecture with SAP Fiori
11 min
Listen to this lesson
A target role architecture answers three questions: what building blocks exist, how they combine into jobs, and who owns each one. In SAP S/4HANA the building blocks are shaped by SAP Fiori. Users reach apps through the launchpad, apps call OData services, and both need authorizations. Designing roles without that picture produces roles that pass a transaction test and fail in the browser.
SAP's starting point: business roles
SAP delivers business role templates that represent jobs, documented in the SAP Fiori apps reference library. Each template comes with the apps a job needs, the launchpad content, and a matching security role in the system whose name starts with SAP_BR_. SAP's guidance is to copy a template into your own namespace and adapt the copy, never to change the original, and to build custom roles where no template fits. Contoso's order-to-cash design starts from the internal sales representative template, for example, and its copy lives in the customer namespace.
How the pieces fit in PFCG
In role maintenance (PFCG), a business catalog is added to a role's menu through the SAP Fiori launchpad catalog option. SAP Learning recommends adding catalogs rather than individual OData services, because the start authorizations for the catalog's services come with it. On the front-end side, a role needs start authorization for the activated OData services; on the back-end side, it needs data access authorization for those services plus the business authorization objects the app checks. With an embedded front-end server, as at Contoso, one role can hold both. Default values maintained in SU24 fill the authorization data. When SAP changes a catalog, roles are updated with the compare function in PFCG or report PRGN_COMPARE_ROLE_MENU; services added manually to a menu are not covered by that comparison.
| Role type | What it holds | Use at Contoso |
|---|---|---|
| Task role (single role) | One task's catalogs, apps and authorization data | Building block, for example "create sales orders" or "post incoming invoices" |
| Derived role | Same menu and authorizations as a master role, different organizational values | One per company code or sales area: 1710, 1810, and 1910 for Wave 2 |
| Business role (composite) | Several task roles that make up one job | Assigned to users, for example accounts payable clerk 1710 |
| Technical and support roles | Administration and launchpad basics such as SAP_FLP_USER copies | Assigned by function, outside business jobs |
Design rules Contoso adopted
- Every business role starts from an SAP business role template, copied to the customer namespace.
- Task roles hold catalogs, not loose services or transactions, except where a legacy transaction has no app.
- Organizational levels (company code, plant, sales area, purchasing organization) are set only in derived roles.
- Each task role is checked against the SoD rule set and contains no conflict on its own.
- Business roles are owned by the process owners (Dan for finance, and the order-to-cash process owner, advised by Maria as O2C key user) and built by Nadia's team.
- Spaces and pages are designed per business role, so users see the apps of their job and nothing more.
- Naming makes scope readable: process, task, organizational value, for example ZCMC_AP_INVOICE_POST_1710.
These rules give Contoso a predictable shape: about 160 task roles, derived per organizational unit, combined into about 120 business roles, replacing roughly 2,900 legacy roles. The numbers matter less than the property they buy: each user's access can be explained as "this person does these jobs, in these organizational units".
Ownership is part of the architecture
SAP Learning stresses that customers fully own their roles and should name role administrators, who work with line-of-business experts, maintain launchpad spaces and pages, grant and revoke access for external implementation team members and enforce least privilege. It also advises against giving that role to people who build or configure the system, such as functional, Basis or development consultants. Contoso's design names a business owner for every business role and keeps role administration in Nadia's team, separate from Kenji's developers and Sam's Basis team.
- Does an SAP business role template match the job?Yes → copy and adapt it · No → build a custom business role from task roles
- Does the task use Fiori apps from a business catalog?Yes → add the catalog to the task role · No → add the legacy transaction and record why
- Does the task vary by organizational unit?Yes → master role with derived roles per unit · No → single task role
- Does the task role conflict with the rule set on its own?Yes → split the task · No → approve for build
What would you do?
Kenji's team wants their developers to maintain business roles in CMD "because they know the apps best". What should Nadia recommend?
- Start from SAP business role templates (SAP_BR_*), copied to your namespace.
- The chain is user, business role, catalogs, apps and OData services, then authorization objects.
- Add catalogs rather than loose services; maintain SU24 defaults; compare roles when catalogs change.
- Task roles as building blocks, derived roles for organizational values, business roles for jobs.
- Name owners: process owners approve, a separate role administration team builds.
Check your understanding · not graded
Lesson check
1. What is SAP's guidance for using business role templates?
2. Why add business catalogs to roles rather than individual OData services?
3. Where should organizational values like company code be set in Contoso's design?
4. Which report updates PFCG roles after a catalog changes?