SAP Analytics Cloud (SAC) provides business intelligence, planning and predictive capabilities, all in one cloud. SAC provides access to enterprise information, i.e., historical data (actuals, past trends) and forward-looking (budget & forecast).

Securing enterprise information within the organisation is equally important as securing it for the outside world. It is even more critical to secure the forward-looking information, i.e., budgets & forecasts as this data reflects the organisation’s strategy and plan for future.

The information in SAC can be presented through Live connection (data resides in the source application, e.g., S/4HANA, BW/4HANA, Datasphere, etc.) and Import connection (data is stored in SAC Dimensions and Models). For Live connection, the data access is controlled in the source application, whereas the data access is controlled in SAC for imported data.

SAC contains a robust framework for securing the information accessible in Dashboards and stories (reports / planning layouts). SAC security framework contains below key elements.

1. Roles – securing the tasks to be performed by users.
2. Content Sharing – securing the access to the SAC content, e.g., stories, models, etc.
3. Data access control – securing the data access.

Refer SAP Analytics Cloud – Security Concepts and Best Practice | SAP Blogs for details on the SAC security concepts and details.

In this blog, I will focus on managing the Data Access Control in SAC, particularly in the context of Planning, Budgeting & Forecasting, as this is the widely used scenario for imported data in SAC. In addition to securing data, the Data Access Control is also essential for optimising performance of planning application through ‘Optimised planning area’ functionality in SAC Planning Models.

In this blog I will demonstrate the use of standard Data Access Control framework for configuring Data Access Control, which is easy to manage and provides flexibility for meeting various business requirements.

SAP Analytics Cloud Data Access Control framework:

1. Dimension based Data Access Control is achieved by switching on the Data Access Control for one or more dimensions for each model. Configuration steps are;

Switch on the ‘Data Access Control in Dimensions‘ option for each model. Choose SAC Menu –> Modeler –> Model –> General Settings –> Access and Privacy.

Figure-1- Switch on Data Access Control in Dimensions

Provide Dimension Member access by assigning Read and Write access to Teams / users in secured dimension/(s).

Figure-2- Provide Dimension Member Access

This option may require significant maintenance effort, if multiple dimensions are secured for multiple teams / users. Moreover, the data restrictions can only be defined for Dimensions existing in the model.

2. Role based Data Access Control is achieved by configuring Dimension member restrictions in Security Roles. Configuration steps are;

Switch on Model Data Privacy for each model that requires data restrictions by choosing SAC Menu –> Modeler –> Model –> General Settings –> Access and Privacy. In this option, switching on of Data Access Control for dimensions is not required.

Figure-3-Switch on Model Data Privacy

After switching on the ‘Model Data Privacy‘, the Model will be available in Security Roles for maintaining data access restrictions.

Figure-4-Model available in Security Roles

The Data Access (Full or Limited) can be defined for the Model in respective security roles. The Read and / or Write Access is defined under the Limited Access option.

Figure-5-Define Full or Limited Access

Note: Read access is automatically provided for dimension members restricted for Write Access. Hence, Read Access is not required to be maintained separately, if Read and Write access is required to be provided at same level.

Maintain the Data Access Filter for the model. Here you can use Dimension ID or Attribute values. The filter contains multiple Operators, e.g., =, >, <, >=, <=, Between, Contains, Is Current User.

Figure-6-Data Access Filter for the Model

Note: Maintain either dimension member ID or attribute in the filter. Both cannot be combined for a Dimension, e.g., ‘#’ (dimension member id) and attribute value/(s). If you are using attribute values in the filter then maintain the attribute value for all members requiring data access restriction.

The Role based DAC provides more flexibility and ease of maintenance. However, multiple roles may be required in this option, potentially one for each Team.

I will now demonstrate how the Security Roles and Data Access Control framework is used with the help of a business scenario.

Business scenario: Data access is required to be restricted by Business Divisions, for entering the budget & forecast data for their respective Cost centres and WBS Elements.

Data Access Design: SAP Datasphere is considered for transforming and integrating the data from the source system/(s). The below design approach is used for meeting the desired business requirements.

1. Planning Model contains Cost centre and WBS Element dimensions. Business Division is not added as a dimension in the model since it is used only for reporting and restricting data access.
2. Add an attribute called ‘Division’ in Cost Centre and WBS Element dimensions.
3. Automate the update of division attribute in Cost centre dimension using Cost centre hierarchy (hierarchy nodes) as maintained in source system. If Divisional hierarchy is not available in source system, either maintain a new hierarchy in source system, or maintain the division attribute manually in SAC.
4. Automate the update of division attribute in WBS Element dimension from Responsible Cost Centre attribute of WBS Element, as available from source system.
5. Configure below set of SAC Security Roles.
   • Task Roles – containing task level restrictions. Role examples are ‘budget_admin, Planner, system_admin, and security_admin’.
   • Data Access Roles – containing data restrictions, leaving task restrictions blank. Role examples are, ‘dac_read_all, dac_division_01′. Maintain Division Attribute values for Cost Centre and WBS dimensions in the Data Access Filter (Figure-6). 
6. Configure Teams, e.g., ‘Budget admin, Division-01, Division-02′, etc.
7. Assign Teams to relevant roles, i.e., Task role/(s) and Data access role/(s). Example, Division-01 Team is assigned in ‘Planner’ and ‘dac_division_01’ roles in this example.

Business outcomes: The key outcomes achieved through this approach are given below.

1. Efficiency and ease of managing Task and Data Access roles, thorough largely automated dimension attribute-based data access restrictions.
2. Centralised management of data access roles without needing to provide Dimension level access to the security team.
3. Performance optimisation through optimum Model structure by using attributes in data access restrictions and not needing to add security relevant Dimensions in the model.
4. Possibility of segregating the responsibility of managing Task roles and Data access roles by different teams.

The Data Access Control model can become complex in a large organisation. I hope this blog provides an approach for configuring Data Access Control for meeting complex business requirements on your projects.