Skip to Content
Technical Articles
Author's profile photo Shefali Srivastava

How to set up data access for models which have security based on shared public dimension via model data privacy in SAP Analytics Cloud Planning


For every planning model, security set up is a must. Many models have shared public dimensions on which the security set up needs to be done. Security set up can be done via various options but the most popular one is via Data Access Control (DAC). In cases where a user needs to access multiple models which share a public dimension on which security needs to be defined, this could be a problematic situation because the user might get access to cost centers for a particular model in which the access should not be granted. The below scenario illustrates such an example and how model data security can solve this situation.


Expense model and HR model share a public dimension called cost_center on which the data security needs to be defined for both the models. A user should have write access to only CC_1 in Expense model and should have write access to only CC_2 in HR model.

Problem statement:

If Data Access Control of cost center dimension is utilized to control the security for both the models, then the user will have access to CC_2 in Expense model while CC_1 in HR model which is not desirable.


IMG 001: Cost center dimension with Data Access Control to provide write access

The user is able to edit both the cost centers i.e., CC_1, CC_2 in both the models whereas only CC_1 should be editable for Expense model and CC_2 for HR model. Below is an example of how the expense template would look like with such a security set up.

IMG002: Both cost centers visible in the expense template

How to solve such a problem? The solution lies with the Model Data Privacy setting in the model.


Note: For all practical purposes, CC_1 cost center would not have any data for HR model because CC_1 would not be a HR related cost center and visa versa. Nevertheless, the user can accidently, input data for CC_1 cost center in HR model so, it is best to not to show up this cost center in the HR model to avoid any erroneous entries.


Step 1: Turn on the model data privacy for both the models.


IMG003: Model data privacy setting turned on for a model

Step 2: Create two separate custom properties for security definition for the 2 models in the public dimension i.e. cost center. In this example “Security for HR” property is for maintaining security for HR model while “Security for Expense” is for Expense model. Any property can be utilized including standard property. Maintain the users as per data access.


IMG004: Custom properties for security maintenance

Note: Multiple users and/or team can also be added as shown below:

IMG005: Multiple users or team assignment to property


Step 3: In the role assigned to the users, click on “Select Model”.


IMG006: Model Data Privacy setting in the role assigned to the users


Maintain the security as defined below for write access.

IMG007: Write access definition


IMG008: Model data privacy setting for HR model

The above screenshot is for HR model. The same needs to be done for Expense model.

TIP: Copy the standard role to customize as per the requirement.

Note: For team, follow the below steps


IMG009: Model data privacy for teams

Now, our setting for security is complete, let us see the output in the input templates.



Let us see how the data is stored in HR model and how is it visible to the HR user who has access to CC_2 cost center only.

IMG010: Data present in the HR model

IMG011: Data visible to the HR user


Similarly, for expense model, only CC_1 would be visible.

IMG012: Data visible to the expense planner

Note: In case the unbooked data for cost center dimension is turned on for the input template, the unbooked cost centers for which the access is not provided will also show up but when an entry is tried to be made on those cost centers the data would not be published and following message will show up.

IMG013: Warning message

Note: If data access control is also enabled along with model data privacy then both will be effective simultaneously.


In this blog, you have learnt to set up access to data regions for models which have security based on public dimensions via model data privacy settings. Hope this blog will help you to find an alternative and effective way to resolve data access issues when security of multiple models is based on common public dimension.

Thanks for reading this blog post, hopefully the blog post was informative. Do share your thoughts and feedback in the comment section.

Please follow the below mentioned links for more blogs on

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jef Baeyens
      Jef Baeyens

      Good summary!

      Would love to use model/role based security in practice but we eventually stepped away from it because of several reasons:

      • Commenting could get disabled entirely, as pointed out in SAP notes 3025423 and 3110011
      • Unbooked shows all master data -as you pointed out-, but also shows in all prompts (data actions, story filters, etc.) while this master data is not relevant to the users.
      • Data Actions run on all master data, and when not scoped properly, will also generate data that cannot be published. Using DAC with 'Hide Parents' option works much better.
      • As a result, end users face too many publishing issues and have no good information or debugging capabilities to find out why exactly
      • Cannot easily maintain the roles (mass update)
      • Cannot easily report on role settings
      • Team assignments with 'contains' are not secure enough. If you create a team called 'SEC_TEST2' it will also provide access
      Author's profile photo KRISHNA PRASAD ALLA

      I have raised the same concern in OSS Note

      Incident 296784/2023 (P3) - Unbooked data option should populate data on authorized members of the dimension only

      1. Users always get panicked when they are allowed to work on unauthorized data.
      2. Allowing users to plan and then skip the planned data while publishing is not be accepted by Business users for below two reasons.
      • It brings a sense of insecurity what data is getting lost.
      • They will not be able to differentiate between authorised set and unauthorized set.
      • Publish option embedded in data action won't work and would prompt the user to publish manually would annoy the planners.