Business Role

A business role answers one question for the SAP Fiori Launchpad: what may this user see and do? It does so through three kinds of content:

• Business catalogs decide which apps a user can reach. Each catalog references tiles and target mappings, so the catalogs in a role define both the app finder content and which intents can resolve.
• Launchpad spaces (and the pages inside them) decide the layout of the home page. A space assigned to a role is visible to every user with that role.
• Authorizations decide what the user can do once an app opens. On-premise, these are the authorization objects of the PFCG role, including the start authorizations for the OData services the apps call. In Cloud Public Edition, they come from the business catalogs and are narrowed by restrictions such as company code.

A user typically holds several business roles, and the launchpad merges their content. A business role is therefore the single assignment that connects a person to SAP Fiori content, layout and data access.

On-premise and in SAP S/4HANA Cloud Private Edition, a business role is a PFCG role whose menu contains SAP Fiori launchpad entries. The usual path:

1. Start from an SAP-delivered template role (SAP_BR_*), for example SAP_BR_PURCHASER, and copy it to the customer namespace.
2. In the role menu, add business catalogs and launchpad spaces. When a catalog is added with its applications included, PFCG pulls in the authorization defaults of the apps it references, including OData service start authorizations.
3. Maintain the remaining authorization values, generate the profile and assign users.

The rapid activation task list SAP_FIORI_CONTENT_ACTIVATION can generate business roles and test users from SAP templates, which is useful for exploring delivered content in a test system. On-premise, a business role is ordinary PFCG role maintenance with SAP Fiori content added to the menu.

In Cloud Public Edition there is no PFCG access. Administrators work with a different set of SAP Fiori apps:

• Business Role Templates lists the templates SAP delivers, each with its business catalogs and launchpad space assignment.
• Maintain Business Roles creates a business role from a template or from scratch, adds business catalogs and spaces, and maintains restrictions per access category (write, read, value help).
• Business Catalogs and Display Restriction Types document what each catalog grants and which restrictions it exposes.

When a role is created from a template, review the access categories for write, read and value help per restriction type, so that write access is a deliberate step. Where catalogs support IAM apps, individual app authorization variants can be switched on or off. If a user holds several roles with the same restriction type but different values, the system aggregates them, which can widen access unexpectedly. In Cloud Public Edition, a business role is built from SAP-managed catalogs and restrictions rather than from authorization objects.

Work through the layers in order:

1. No tile on the home page, but the app is found by search. The catalog is in the role, but the app is not on a page in any space the user holds. Add it to a page or assign the right space.
2. Tile visible, navigation fails. The target mapping behind the tile is not reachable through the user's catalogs, or its device or parameter rules do not match. On-premise, run /UI2/FLIA for the user and intent.
3. App opens, then shows an authorization error or no data. The OData start authorization or a business authorization is missing. On-premise, check SU53 or record the checks with STAUTHTRACE in the system where the check fails. In Cloud Public Edition, review the role's restrictions and use the Display Authorization Trace app.
4. The role was changed, but the user sees nothing new. On-premise, the profile may not be regenerated or the user assignment not compared.

A missing app is almost always a business role composition problem, not a broken app.

1. Editing SAP templates instead of copies. SAP_BR_* templates are references; changes belong in customer-namespace copies, or upgrades and corrections become hard to compare.
2. One role per person. Roles designed around individuals multiply quickly and break with every reorganization. Design roles around positions and tasks.
3. Mixing critical and common apps in one catalog. Anyone with the role can reach every app in the catalog through search and the app finder, even when the app is not on a page.
4. Wildcard OData authorizations on-premise. Granting all services with S_SERVICE set to an asterisk is convenient in a sandbox; SAP recommends single service authorizations in production.
5. Treating role assignment as the rollout. Users who receive a role without a meaningful space and pages face a near-empty or confusing home page.

Most business role problems are design decisions taken too early or too late, and a business role review should cover catalogs, spaces and authorizations together.