Skip to content
Hands-onSAP Datasphere

Hands-on: apply dimension data access controls to facts in Datasphere

Step by step: make the row-level security of a dimension filter fact data too in SAP Datasphere, with sample data and a View as User test.

By 13 min read
SAP Datasphere diagram: a permissions table feeds a data access control on the region dimension, whose association passes the security on to the sales fact view and the analytic model
Table of contents

Row-level security in SAP Datasphere is built with data access controls (DACs). The natural place to put it is the dimension: “Ana only sees the North and Central regions”. The catch is that protecting the dimension was not enough to properly protect the facts linked to it through an association. In wave 2026.6 (March 2026) SAP added an option to the fact-to-dimension association, Apply Dimension Data Access Controls to Fact, which applies the dimension’s DAC directly to the fact data. In this hands-on guide I build it from scratch and test it user by user, without needing any extra real users.

What we are going to build

A sales-by-region model, typical of a distribution company with regional branches. By the end you will have:

  1. A permissions table T_PERM_REGION (user → region) and a Single Values DAC DAC_REGION on top of it.
  2. A dimension V_REGION protected by DAC_REGION.
  3. A fact view V_SALES with an association to V_REGION that passes the DAC on to the fact.
  4. An analytic model AM_SALES, a View as User test on the fact view for three fictitious users, and a test on the model with your own user.

All technical names are examples: use your own naming convention.

Why it matters

SAP sums it up in one sentence: without this option, users may see null aggregate values for records they are not allowed to see. My test shows it clearly: the DAC filters the dimension, but the fact does not inherit it. In the fact view the user still sees every sale, and in the analytic model they see the amounts of forbidden regions with the region name as (Null). The alternative without this option is to apply the DAC to the fact view or the analytic model as well, and maintain the mapping in two places. With the new option, the rule lives in the dimension and the fact inherits it.

Step by step

  1. Step:Upload the sample data

    Download the three CSV files, all with fictitious data: regiones.csv, ventas.csv and permisos_region.csv. The file names are in Spanish; the columns are in English.

    regiones.csv has four regions (NOR, CEN, SUR, EST: North, Central, South, East). ventas.csv has 16 sales, four per region, adding up to 22,450:

    Region Sales Amount
    NOR 4 4,450
    CEN 4 6,050
    SUR 4 6,000
    EST 4 5,950

    The permissions table assigns regions to users:

    permisos_region.csv
    USER_ID,REGION_ID
    TU_USUARIO,NOR
    TU_USUARIO,CEN
    TU_USUARIO,SUR
    TU_USUARIO,EST
    ANA.DEMO,NOR
    ANA.DEMO,CEN
    LUIS.DEMO,SUR

    Before uploading it, replace TU_USUARIO with your own SAP Datasphere user ID, in the format required by the tenant’s identity provider. This matters: a user who is not in the permissions table sees no records at all in protected views, and that includes you. ANA.DEMO and LUIS.DEMO are fictitious; they do not need to exist in the tenant.

    Which format? Don’t guess: the DAC editor (step 2) shows an example built from your own user right below Permissions Entity. In my trial tenant it was the email address in lower case, not the USR… code you see in the space name. My first upload used the code and I had to redo it.

    In the Data Builder, open the import menu in the toolbar and choose Import CSV File to create T_REGION, T_SALES and T_PERM_REGION. In the import editor, select each column and open Details to check its type. In my test Datasphere correctly detected AMOUNT as Number and SALE_DATE as Date. Deploy each table with its technical name.

    If you already uploaded T_PERM_REGION with the wrong ID, you don’t need to delete it: in the table editor, the Upload Data from CSV File button opens the Import CSV File dialog; select Delete Existing Data Before Upload and upload the corrected file.

  2. Step:Create the DAC on the permissions table

    In the Data Builder, choose New Data Access Control and fill in:

    Property Value
    Business / Technical Name DAC_REGION
    Structure Single Values
    Permissions Entity T_PERM_REGION
    Identifier Column USER_ID
    Criteria REGION_ID

    In the Criteria section, Create adds a row; in my case it proposed REGION_ID straight away, the only column left. Save and deploy. With Single Values, each user sees the records matching any of the values assigned to them: for Ana, North or Central.

    If your permissions table is shared from another space, you cannot use it directly as the permissions entity: wrap it in a view in your own space first.

    Deployed DAC_REGION editor: Structure Single Values, Permissions Entity T_PERM_REGION, Identifier Column USER_ID, the note with the identity provider's ID format (hidden) and REGION_ID under Criteria
    DAC_REGION deployed. Below Permissions Entity, the editor tells you which ID format it expects (I have hidden my email).

  3. Step:Create and protect the dimension

    Create an SQL View V_REGION:

    V_REGION.sql
    SELECT "REGION_ID", "REGION_NAME"
    FROM "T_REGION"

    Set Semantic Usage = Dimension, validate the SQL so the attributes show up, and make REGION_ID the key (pencil icon on Attributes, key column). If you like, make REGION_NAME the text of REGION_ID.

    In the view’s side panel, scroll down to the Data Access Controls list. Click +, choose DAC_REGION and, in the Join section, drag the view’s REGION_ID onto the DAC’s REGION_ID criterion: in my test it was not mapped automatically, even though the columns have the same name. Every criterion of the DAC must be mapped, otherwise the filter will not work correctly. Deploy.

    V_REGION side panel with DAC_REGION selected: Join section with the view's REGION_ID linked to the DAC's REGION_ID criterion
    DAC_REGION join on V_REGION: the view's REGION_ID linked to the DAC criterion.

    Check it right away in the V_REGION Data Viewer with View as User (the person icon in the data panel toolbar): with ANA.DEMO only CEN and NOR are returned. The dimension is now protected.

  4. Step:Create the fact with the association (without the option yet)

    Create an SQL View V_SALES:

    V_SALES.sql
    SELECT "SALE_ID", "SALE_DATE", "REGION_ID", "AMOUNT"
    FROM "T_SALES"

    Set Semantic Usage = Fact, SALE_ID as the key and AMOUNT as a measure (drag it to Measures). In the Associations section, click + > Association and choose V_REGION. Datasphere mapped the fact’s REGION_ID to the dimension’s REGION_ID key on its own.

    In the association panel, below To, you can already see the Apply Dimension Data Access Controls to Fact checkbox. For now, do not select it: I want you to see the old behaviour first. Deploy.

    Then create the analytic model AM_SALES by dragging V_SALES onto the canvas. The add dialog already proposes the associated dimension REGION_ID (V_REGION) and the AMOUNT measure. Deploy it.

  5. Step:Check the 'before' with View as User

    In the V_SALES editor, open the Data Viewer, click View as User, enter ANA.DEMO and click View.

    Result in my test: Ana sees all 16 sales, including SUR and EST, and the total is still 22,450. The dimension filters her, but the fact view does not.

    One detail: View as User only simulates DACs that are deployed and applied in the current space. It is not available for a view shared from another space.

    On AM_SALES, which is where SAP talks about null aggregate values, View as User doesn’t help. The help says it exists in the analytic model editor; in my tenant (October 2026) it only appears when you select the fact source or the dimension on the canvas, and then the Data Viewer shows that view’s data (V_SALES or V_REGION), just as if you opened it in its own editor. With the model selected, neither the Data Viewer nor Preview offers it.

    The trick is to test with your own user. Temporarily remove SUR and EST from your user in T_PERM_REGION (upload the CSV again without those two rows, with Delete Existing Data Before Upload). Open AM_SALES in Preview and put REGION_ID and its REGION_NAME attribute in the rows (expand REGION_ID under Available Objects).

    AM_SALES preview without the option, for a user who only has NOR and CEN: CEN Centro 6,050, EST (Null) 5,950, NOR Norte 4,450 and SUR (Null) 6,000
    AM_SALES without the option and with my user limited to NOR and CEN: EST and SUR show REGION_NAME (Null), but with their amounts.

    This is exactly what SAP describes: the DAC hides the dimension records, so REGION_NAME shows as (Null) for EST and SUR, but the fact amounts are still there and the total is 22,450. The user doesn’t know which region they belong to, but can see how much the regions they shouldn’t see are selling.

  6. Step:Pass the DAC on to the fact

    Go back to V_SALES, open the association to V_REGION and select Apply Dimension Data Access Controls to Fact. Deploy the view.

    V_SALES to V_REGION association panel with the Apply Dimension Data Access Controls to Fact checkbox selected and the REGION_ID to REGION_ID mapping
    The V_SALES to V_REGION association with the checkbox selected and the REGION_ID → REGION_ID mapping.

    In the V_SALES side panel, the Data Access Controls list still has 0 DACs of its own, but it now shows DAC_REGION in the Applied via Dimensions sub-list, with the note Applied to V_REGION. That sub-list is handy when reviewing inherited models: it tells you which security arrives through associations without opening every dimension.

    V_SALES side panel: Data Access Controls (0) and, in the Applied via Dimensions sub-list, DAC_REGION with the note Applied to V_REGION
    V_SALES has no DACs of its own, but inherits DAC_REGION through the association.

    Don’t expect to see the change in AM_SALES. Its panel has no Applied via Dimensions sub-list, and DAC_REGION shows up under Applied via Sources with V_REGION as the source whether the checkbox is selected or not: I checked by clearing it and redeploying. It is listed there because V_REGION is one of the model’s sources, not because of the new option. The analytic model stayed Deployed after I changed the fact view; it did not ask to be redeployed.

    Where you do see the change is in the data. Run the AM_SALES Preview again with your user still limited to NOR and CEN:

    AM_SALES preview with the option enabled, for a user who only has NOR and CEN: only CEN Centro 6,050 and NOR Norte 4,450
    With the checkbox selected, the same user only sees CEN and NOR (10,500). The (Null) rows are gone.

    Now the fact inherits the DAC: only CEN and NOR show up and the total drops to 10,500. When you are done, upload the CSV again with your four regions. You don’t need to redeploy anything: the model picks up changes to the permissions table when you reload the browser page. I repeated it twice more and a plain F5 was enough. Once, though, the Preview kept showing the previous result for a few minutes while V_SALES already showed the new one; if that happens, wait a bit and reload.

Validation

Repeat View as User on V_SALES for each user. If the Data Viewer shows the error You can’t see data in a view protected by a data access control until all changes are deployed right after deploying, close the view and reopen it from the Data Builder: that cleared it for me. This is what I got with the CSV data:

User Allowed regions Visible sales AMOUNT total
ANA.DEMO NOR, CEN 8 10,500
LUIS.DEMO SUR 4 6,000
MARTA.DEMO (not in the table) — 0 —
Your user All four 16 22,450

In AM_SALES, with my user limited to NOR and CEN, the Preview went from 22,450 with two (Null) rows to 10,500 once the checkbox was selected, just like ANA.DEMO on the fact view.

MARTA.DEMO is my favourite test: it confirms that anyone missing from the permissions table sees nothing. That is the correct, safe behaviour, but in real projects it creates “I can’t see any data” tickets on day one. If your team loads permissions from an HR file or an identity system, check first that every active user has at least one row.

V_SALES Data Viewer with View as User active for ANA.DEMO: 8 sales, only from the NOR and CEN regions
V_SALES viewed as ANA.DEMO: 8 sales, only NOR and CEN (10,500 in total). Before selecting the checkbox she saw all 16.

Common mistakes

Symptom Cause Fix
A user sees no data They have no row in the permissions table Add them, even with a single region. Watch out for your own user.
You see no data even though you are in the permissions table The ID is not in the identity provider’s format Use the format shown in the DAC editor (in the trial, the lower-case email) and reload the table.
The Data Viewer asks you to deploy although the view is deployed The editor has not refreshed its status after deployment Close the view and reopen it from the Data Builder.
You change the permissions table and the model Preview doesn’t change The Preview still shows the previous result Reload the browser page; if it does not change, wait a few minutes and reload again. No redeploy needed.
View as User does not filter anything The DAC is not deployed, or it was applied in another space Deploy the DAC and the view. View as User only simulates deployed DACs in the current space.
You cannot use the permissions table in the DAC The table is shared from another space Create a view on it in your space and use that as the permissions entity.
Data validation shows rules as unavailable The view, or one of its sources, is protected by a DAC This is a documented limitation: validate keys before applying the DAC, or on an unprotected view.
You cannot persist a view that consumes V_SALES A view consuming another view with a DAC cannot be persisted Persist below the protected view, or apply the DAC to the top view instead.
In the analytic model you cannot map a DAC to a dimension attribute The model has standard, reference date or X variables This is a documented limitation. Applying security in the views, as in this guide, is the alternative I would use.

A note on persistence: the documentation says a view with a DAC can be persisted, but I have not found what exactly happens with a DAC inherited through an association. If you persist the fact view, test it before relying on it.

My recommendation

For new models, I would put the DAC on the dimension and select the option on every fact-to-dimension association that needs to inherit it. One rule in one place is easier to audit than three copies mapped by hand. For existing models, start with the Applied via Dimensions sub-list of each fact view: it tells you which facts already inherit their dimensions’ security. In the analytic model, Applied via Sources tells you which DACs exist in its sources, but not whether the fact inherits them. And before going live, always run the three-user test: one with everything, one with part of the data and one with nothing.

Sources

Keep reading