Data-Level Security in SAC: Data Access Controls and Row-Level Restrictions

Explanation

Once application-level access is configured (roles, teams, folder sharing), the second and often more business-critical layer of SAC security is data-level security: ensuring that even if two users can open the same story, they see only the rows of data relevant to their organizational scope, such as their own cost center, region, or sales territory. In SAC this is implemented primarily through Data Access Controls (DAC). A Data Access Control is a security object that maps a dimension in a model to a restricting value, and associates that restriction with specific users or teams. For example, a DAC might be built on the 'Region' dimension of a Sales model, with rules such as 'Team = EMEA_SALES maps to Region = EMEA' and 'Team = APAC_SALES maps to Region = APAC'. When a user belonging to EMEA_SALES opens any story built on that model, SAC automatically filters all queries to Region = EMEA, regardless of what the story visually requests, because the restriction is enforced at the model/query level, not the story layer. This is what distinguishes true data security from a story-level filter, which any story editor could simply remove. DACs can be built on both planning-enabled acquired (imported) models and, with some constraints, on live data connections, though the exact mechanics and limitations for live connections (for example live HANA views or live SAP Datasphere connections) differ from those for imported/acquired models, and the level of enforcement can depend on whether row-level security is already handled upstream in the source system. When SAC connects live to SAP Datasphere, it is common to push data-level security down to Datasphere's own data access controls at the view level rather than duplicating the logic in SAC, especially when the same Datasphere views feed multiple consuming tools beyond SAC. Conversely, for imported/acquired models where data physically resides in SAC's in-memory engine, DAC is typically the only enforcement point. An important architectural decision is where to enforce security: at the source (Datasphere/HANA), in SAC via DAC, or in both. Enforcing purely in SAC is simpler to administer for SAC-only consumption but creates duplicate logic if the same data is also consumed by other BI tools. Enforcing at the source is more robust and reusable but requires the source system's security model to be maintained by a team with visibility into all downstream consumers, and any live-connection nuance must be validated because not all restriction types propagate identically across every connection type. Operationally, DAC configuration requires: (1) identifying the dimension that represents the security boundary (region, cost center, company code), (2) deciding whether restriction is by explicit value list, hierarchy node, or an owner/manager pattern using a special 'owner' dimension, and (3) associating restriction values to Teams (preferred) or individual Users. Testing must include impersonation or a representative test user per boundary, since a misconfigured DAC can silently show zero rows (over-restrictive) or all rows (under-restrictive, if the DAC does not apply to a model version or is not activated). Troubleshooting DAC issues typically starts by checking: is the DAC assigned to the correct model version being used by the story, is the user's team correctly mapped to a restriction value, and whether the story uses a live connection where enforcement might rely on source-side controls instead. A frequent production issue is that a DAC built and tested on a model works, but after a model republish or structural change, the DAC mapping silently detaches and must be reattached and revalidated.

Code example

-- Representative DAC definition (conceptual, configured via SAC UI, not a scripting language): DataAccessControl: DAC_SALES_REGION  Model: SalesPlanningModel  Restricted Dimension: Region  Mapping Type: Team-based  Mappings:    Team = EMEA_SALES_TEAM  -> Region IN ('EMEA-DE','EMEA-FR','EMEA-UK')    Team = APAC_SALES_TEAM  -> Region IN ('APAC-JP','APAC-AU')    Team = GLOBAL_FIN_ADMIN -> Region = '*'  -- unrestricted, use sparingly -- Validation checklist (manual, not code):-- 1. Confirm DAC status = Active and linked to current model version-- 2. Log in as impersonated test user per team, verify row counts match expected scope-- 3. Re-test after any model dimension or hierarchy change

Real project scenario

A retail client consolidated regional sales planning into one shared SAC model to reduce maintenance. After go-live, regional controllers could see other regions' committed numbers because the DAC had been built and tested against a draft model version, and the published production model version used for live stories was a newer republish that did not automatically inherit the DAC linkage. The fix required reattaching the DAC to the current model version and adding a release-checklist step to re-verify DAC linkage after every model structural change.

Common mistakes

• Building and testing a DAC on one model version, then republishing the model without reverifying the DAC is still linked • Assuming a story-level filter provides real security, when it can be removed or bypassed by any story editor • Mapping DAC restrictions to individual users instead of teams, causing high maintenance overhead • Not testing with an impersonated low-privilege user, only validating as an administrator who bypasses restrictions • Duplicating row-level logic in both SAC and the source system inconsistently, causing mismatched results between tools

Best practices

• Always map Data Access Controls to Teams rather than individual users for maintainability • Re-validate DAC linkage to the model version as part of every model change/release checklist • Prefer enforcing row-level security at the source (e.g., Datasphere) when multiple tools consume the same data, to avoid duplicated and inconsistent logic • Test data security with impersonated non-admin test users per restriction group before go-live • Avoid unrestricted 'catch-all' team mappings except for a small, clearly documented administrative group

Interview angle

Interviewers often ask how to prevent a user from seeing other regions' data in a shared model; the expected answer distinguishes DAC-based data-level enforcement from story-level filtering and explains team-based mapping plus the importance of validating enforcement after model changes, along with awareness that live-connection scenarios may push enforcement to the source system instead.