Concept card

Role-Based Access Control (RBAC)

As of 2026-07-23

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Role-Based Access Control (RBAC)?

RBAC and DAC answer two different questions that get conflated constantly — RBAC gates whether a user can open an object, DAC filters which rows of that object they can see.

What it is

RBAC (Role-Based Access Control) is the authorization model where permissions attach to roles, and roles attach to users — never permissions to users directly. In the SAP estate this shows up at two distinct layers a senior consultant must never conflate: the ABAP/S-4HANA layer (PFCG roles, authorization objects, composite roles) and the Datasphere/analytics layer (space privileges, scoped roles, and Data Access Controls / DAC — companion C008).

Two layers, two purposes. PFCG roles gate what a user can DO in the source ERP (transaction access, org-level authorizations via fields like company code and plant). Datasphere space-level roles gate what a user can SEE and BUILD inside a space (Viewer, Modeler, Space Administrator, plus custom scoped roles). DAC then filters ROWS within an object the user already has access to. RBAC answers "can this user open this object"; DAC answers "which rows of that object can this user see". Confusing the two is the most common governance design mistake in Datasphere rollouts.

Why role count balloons. A Tier-1 SAP landscape typically ends up with 50-200 distinct roles once org-level authorizations (company code, plant, sales org) are cross-multiplied with functional scopes (Finance, Procurement, Sales) and space-level Datasphere roles. Design discipline — role naming conventions, a role-to-business-function matrix, and a quarterly access review — is what keeps this from becoming unmanageable technical debt.

Why it matters

PFCG roles (ERP-side transaction access) and Datasphere space roles (Viewer/Modeler/Admin) are two distinct layers — conflating them is the single most common governance design mistake in Datasphere rollouts.
Role count naturally balloons to 50-200 once org-level scopes (company code, plant, sales org) cross-multiply with functional scopes and space roles — without discipline it hits 500+ and becomes unauditable.
One-off role exceptions granted per user request, rather than mapped to the existing matrix, is exactly how Tier-1 landscapes end up with roles nobody can audit.

Key points

RBAC = permissions attach to roles, roles attach to users — never permissions directly to users.
Two distinct layers: PFCG/ABAP roles (object access) vs Datasphere space roles (space access) — do not conflate either with DAC (row access).
50-200 roles is normal at Tier-1 scale once org-level scope × functional scope × space role are cross-multiplied.
Role matrix (business function × system layer × org scope) must be signed off before go-live, not built ad hoc.
Role-Based Access Control (RBAC) is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.
For non-AI use cases, still define quality, adoption, and operating ownership.

Terms used on this page

PFCG role: SAP ABAP role-maintenance transaction; bundles authorization objects into a role, then assigns the role to users.
Authorization object: ABAP-layer permission unit combining fields (e.g. company code, plant) with activity codes — the atomic unit PFCG roles bundle.
Space role: Datasphere space-level role (Viewer, Modeler, Space Administrator) gating what a user can see and build inside a space.
Data Access Control (DAC): Row-level filter applied after RBAC already grants object access; answers 'which rows', not 'which object'.
Composite role: PFCG role bundling several single roles into one job profile, easing assignment at scale.
Role matrix: Business-function × system-layer × org-scope grid used to design roles before rollout, not after.
Org-level authorization: Authorization scoped by an organizational field such as company code, plant, or sales organization.
Access review: Periodic (typically quarterly) audit reconciling granted roles against the role matrix and each user's current job function.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks.

Open in the app →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.