Cross-Space Sharing and Data Access Controls in Datasphere Spaces

Explanation

Once an organization moves beyond a single Datasphere space, two recurring requirements appear: reusing curated data across teams without duplicating pipelines, and making sure that shared data does not leak rows a given consumer should not see. Both problems are solved inside the space model, but they require deliberate design rather than default behavior. Sharing across spaces: every object you build (a table, a view, an analytic model) lives physically inside one space, which owns its storage quota and lifecycle. To let another space consume that object, the owning space must explicitly share it into the target space. This is not a copy - the consuming space gets a reference to the same underlying object, so data is not duplicated and updates are reflected immediately in every space that consumes it. Sharing is one-directional and must be granted per target space; there is no 'share to everyone' shortcut, which is a deliberate governance control so that data owners retain visibility over who consumes their models. A shared object appears in the consuming space's repository under a 'shared' or 'imported' category, and by default it is read-only there: you cannot edit the shared object's definition from the consuming space, only build on top of it (for example, a new view that joins a shared dimension with locally owned data). Why this matters operationally: many projects start by rebuilding the same currency conversion table or calendar dimension in every space because sharing was not planned early. This causes model drift when one team updates their copy and others do not, and it wastes storage quota. The recommended pattern is a 'foundation' or 'core' space that owns master data and shared dimensions, sharing them outward to consuming line-of-business spaces which layer their own business logic on top. Data Access Controls (DACs): sharing an object openly is often not enough because different consumers should see different subsets of rows - for example, a shared sales fact table should show only EMEA rows to the EMEA planning space and only APJ rows to the APJ space. A DAC is a structure that maps user attributes (such as a mapped user ID, a custom user attribute, or an organizational value) to permitted values in a column of the target table or view. Once a DAC is created, it is associated with the object; from that point, any query against the object is filtered so that only rows matching the requesting user's mapped values are returned, regardless of which space or story is querying it. DACs can use single-value mapping, multiple values per user, or hierarchical mappings for org-based structures. Combining sharing and DACs: because DAC enforcement travels with the object, a single shared table can be exposed to multiple spaces while each consumer only ever sees rows relevant to their scope - the object owner does not need to build separate filtered views per consumer, which keeps the semantic model DRY and auditable. Runtime behavior and troubleshooting: DAC evaluation happens at query time based on the requesting user's identity as resolved by the space's authentication and user mapping. If a business user reports seeing no data (rather than wrong data), the most common cause is a missing or incorrect user mapping entry in the DAC table for that user - this is different from a story-level filter problem and should be checked before touching the model itself. If a user sees too much data, check whether the DAC was actually attached to every consuming view (attaching a DAC to a base table does not automatically apply if a downstream view bypasses the association, depending on how the view was built) and whether space administrators or object owners are exempt as designed. Testing DACs requires impersonating or logging in as a representative test user per segment, since space administrators typically bypass row-level restrictions. Governance implications: because a shared object plus DAC becomes a shared security boundary, changes to either the shared model or the DAC mapping table should go through the same change control as any shared master data - an uncoordinated change in the foundation space can silently alter what every downstream consuming space sees.

Code example

-- Illustrative example of a Data Access Control mapping table-- (conceptual structure, not a specific SAP API or transaction) -- Step 1: Define a mapping table that associates users with allowed valuesCREATE TABLE DAC_REGION_MAPPING (  USER_ID       VARCHAR(100),   -- mapped Datasphere user identity  REGION_VALUE  VARCHAR(50)     -- value permitted for that user, e.g. 'EMEA'); -- Example rows: each user can be mapped to one or more regionsINSERT INTO DAC_REGION_MAPPING VALUES ('jsmith@company.com', 'EMEA');INSERT INTO DAC_REGION_MAPPING VALUES ('jsmith@company.com', 'APJ');INSERT INTO DAC_REGION_MAPPING VALUES ('rkumar@company.com', 'APJ'); -- Step 2: Conceptually, this mapping table is created as a Data Access Control-- object in Datasphere and associated with the 'REGION' column of a shared-- fact view, e.g. SALES_FACT_SHARED.REGION -- Step 3: When a consuming space queries the shared view, the effective-- query behaves as if this filter were applied automatically:SELECT * FROM SALES_FACT_SHAREDWHERE REGION IN (  SELECT REGION_VALUE FROM DAC_REGION_MAPPING  WHERE USER_ID = CURRENT_USER_MAPPED_ID());-- The consuming space developer never writes this WHERE clause manually;-- the DAC association enforces it transparently at query time.

Real project scenario

A retail customer built a foundation space owning a single 'Global Sales Fact' view fed from S/4HANA replication. Five regional planning spaces (EMEA, NA, LATAM, APJ, MEA) needed to build local forecasting models on top of the same fact data but were only entitled to see their own region's transactions, and a small central FP&A team needed to see all regions. The team shared the Global Sales Fact view into all five regional spaces plus the FP&A space, then attached a single Data Access Control keyed on a REGION_MAPPING table maintained by the security team. FP&A users were mapped to all five region values, while regional planners were mapped only to their own region. This avoided building five separate filtered copies of the fact view and ensured that when the source replication refreshed nightly, all six consuming spaces saw consistent, correctly filtered data without any additional maintenance in the consuming spaces.

Common mistakes

• Rebuilding the same dimension or fact table independently in multiple spaces instead of sharing from a foundation space, causing model drift. • Assuming a shared object can be edited from the consuming space; shared objects are read-only references and must be modified in the owning space. • Forgetting to update the DAC mapping table when new users or new organizational values are onboarded, leading to users seeing no data. • Attaching a DAC to a base table but not verifying that every downstream view built on it still enforces the restriction as expected. • Testing DAC behavior only as a space administrator, whose access often bypasses row-level restrictions, masking real end-user issues. • Treating DAC mapping tables as static and forgetting they need the same change control as other shared master data.

Best practices

• Establish one or a small number of foundation spaces to own shared master data and dimensions, sharing them outward rather than duplicating. • Attach Data Access Controls at the lowest reusable object level so every downstream consumer inherits the same enforced filtering. • Maintain DAC mapping tables under the same governance and change approval process as other shared security artifacts. • Test row-level security by impersonating representative end users per segment, not by testing only as an administrator. • Document which spaces consume which shared objects so that owners can assess the impact of a model change before deploying it. • Periodically audit DAC mappings against current organizational structure to catch stale or orphaned user entries.

Interview angle

Interviewers use this topic to check whether a candidate understands the difference between object-level sharing (who can see a model exists) and row-level security (what data within that model a user can see), and whether they know these are separate, composable mechanisms in Datasphere. Strong answers describe a foundation-space sharing pattern, explain that DACs filter at query time based on mapped user identity, and can describe a realistic troubleshooting flow distinguishing 'no data' (mapping missing) from 'too much data' (DAC not applied to a downstream view) symptoms.