Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Datasphere security model — object access, row access, and the seams

As of 2026-08-14

The model rests on a distinction that sounds pedantic and decides everything: can this user open this object, and which rows of it may they see. Those are two questions answered by two mechanisms, and conflating them is the most common governance design error on Datasphere rollouts. The three places where enforcement silently stops are all seams — where data leaves the platform, gets copied, or is read by another engine.

The two layers, and why they are not interchangeable

Object access is role-based: permissions attach to roles, roles attach to users, never permissions to users directly. In Datasphere that means space-scoped roles — viewer, modeller, administrator, plus custom scoped roles — deciding whether a user can open, build in or administer a space.

Row access is a filter. Data access controls apply inside an object the user can already open, restricting which rows are returned by attributes such as company code, plant or sales organisation.

Role design decides whether the estate stays auditable

A Tier-1 SAP landscape typically ends up with 50 to 200 distinct roles once org-level scope — company code, plant, sales organisation — is cross-multiplied with functional scope and space-level roles. That is the normal number for a designed estate.

The failure mode is role explosion by exception. Granting a bespoke role per request, rather than mapping it to an existing role or adding a dimension to the matrix, is how landscapes reach 500-plus roles that nobody can audit, at which point access review stops being a control.

What prevents it is unglamorous: build the matrix before go-live, have the data owner sign it, and treat every later request as an exception with one named approver.

Seam one: the copy that drops the filter

A story bound live to an analytic model inherits row filtering automatically — the query is pushed down and the user sees only what their permissions allow. An imported flat model does not. The data is copied at refresh time, and every user with access to the story sees every imported row.

The lineage chain breaks at the same boundary, so the derivation path is unavailable exactly when someone asks where a number came from. Tolerable for one-off exploratory analysis on non-governed data; in a regulated domain it fails on the data-protection and AI-governance sides at once, and it fails invisibly, because the report looks correct to whoever built it.

Seam two: the other engine reading the same data

Once a lakehouse sits alongside Datasphere, two governance systems describe the same rows. Rules defined on the SAP side must be verified as inherited on the reading side, never assumed: a misconfigured share exposes more than the source model intended, silently.

The specific risk is a mismatch between the row-level rules in the SAP catalog and those in the lakehouse metastore: a notebook can end up seeing rows a user in the same role cannot see through a report. Nothing errors, because both systems are behaving correctly according to their own configuration.

The design answer is one authoritative rule set, with the other treated as an enforcement point to be verified — and the verification written into the go-live checklist rather than assumed from a diagram.

Seam three: what leaves the building

An outbound share is a credential and a contract. Recipient credentials are token-scoped per consumer and independently revocable, which is a good property and only helps if it is exercised: rotation quarterly by default, monthly in regulated industries, with the access log wired into whatever the organisation actually monitors.

The complementary gap runs the other way: a user blocked in the catalog may still query the underlying warehouse or lake directly if their source-system credentials were never restricted.

Frequently asked

What is the difference between a space role and a data access control?

A space role answers whether a user can open an object at all; a data access control filters which rows they see inside an object they can already open. Conflating them is the classic design error here.

Do row-level filters follow the data into a report?

Only on a live binding. A story bound live to an analytic model inherits filtering and lineage; an imported flat model copies the data and drops both, so every user with story access sees every imported row.

How do we keep access consistent with a lakehouse alongside?

Keep one rule set authoritative and verify enforcement on the reading side rather than assuming it. The failure is silent: a notebook can see rows a report-user in the same role cannot, with neither system reporting an error.

How many roles should we expect?

50 to 200 at Tier-1 scale once org scope is cross-multiplied with functional scope and space roles. Past 500 usually means bespoke roles were granted per request rather than mapped to a matrix.

What this page is built on

Read next