Designing Row-Level Data Access Control in SAC Models

Explanation

Role-based security in SAC controls what a user can see and do at the object level (which stories, models, or folders they can access), but it does not restrict which rows of data within a model a user is allowed to view. That is the job of Data Access Control (DAC), SAC's mechanism for row-level security. This distinction matters enormously in real deployments: a sales manager and a finance controller may both have 'View' access to the same regional sales model, but each should only see data for their own region, cost center, or profit center. Without row-level security, every authorized user sees every row, which is both a data governance risk and often a contractual or regulatory problem (e.g., HR compensation data, customer-specific pricing). Data Access Control in SAC works by linking a dimension (or a specific attribute of a dimension) in a model to a mapping of user attributes. You typically build a dedicated 'Data Access Control' object in the modeler, choose the model and the dimension to secure (for example, Region, Cost Center, or Company Code), and then define which values each user or team is permitted to see. This mapping can be maintained manually inside SAC, or driven by a user attribute stored in the SAC user profile (such as a custom attribute populated during provisioning or SSO), or driven by data coming from a source table/model that lists user-to-value assignments. The source-table approach scales much better for large user populations because it can be refreshed as part of data loads rather than manually maintained by an administrator. Once a Data Access Control object is created and activated, it is applied to the target model, and from that point every story, application, or planning model consuming that model automatically inherits the row filtering — there is no need to rebuild each story. This is a key operational advantage: security logic lives centrally in the model layer, not scattered across dozens of stories. A critical design decision is how DAC interacts with public versus private dimensions, and with model types. Not all dimension types or model configurations support DAC identically, and planning models have additional considerations because write-back must also respect the same restrictions (a user should not be able to plan or input values into cost centers they cannot see). Teams need to validate, per model, whether DAC restricts input as well as display, and test this explicitly rather than assuming symmetrical behavior. When the model is fed from a live connection (e.g., to S/4HANA or BW), row-level security may already be enforced by the source system's own authorization concept (analysis authorizations in BW, or authorization objects in S/4HANA). In that case, layering SAC's own DAC on top can either be redundant, complementary, or, if misconfigured, can create confusing situations where a user sees no data at all because both layers filter independently and their value sets do not intersect. For live connections, the recommended approach is usually to rely primarily on the source system's authorization model and use SAC DAC sparingly, only for scenarios the source cannot express. For imported or acquired models (data physically loaded into SAC or SAC-managed storage), DAC is typically the primary enforcement mechanism since there is no live source authorization to depend on. Testing row-level security requires impersonation or dedicated test users representing different authorization profiles, since the administrator's own account typically bypasses restrictions or does not represent a normal end-user's view. Teams should build a test matrix: each representative role/attribute combination, expected visible rows, and expected input behavior in planning contexts, then validate before go-live and after every relevant model or DAC change.

Code example

-- Conceptual mapping table used as the SOURCE for a Data Access Control object-- (this is a data model concept, not a literal SAP transaction or API) -- Table: USER_REGION_ACCESS-- Columns: USER_ID (matches SAC user ID or SSO attribute), REGION_ID (matches Region dimension member) -- Example rows:-- USER_ID       REGION_ID-- j.smith        EMEA-- j.smith        APAC-- a.wong         APAC-- p.diallo       AMER -- Design steps performed in SAC Modeler (described procedurally, not as literal UI paths):-- 1. Create a Data Access Control object.-- 2. Select the target model (e.g., SalesPlanning) and the dimension to secure (Region).-- 3. Choose 'Read from a model/table' as the mapping source and point it to USER_REGION_ACCESS.-- 4. Map USER_ID to the SAC user identifier and REGION_ID to the Region dimension.-- 5. Activate the Data Access Control object and assign it to the SalesPlanning model.-- 6. Test using a non-admin test account mapped to a single region and confirm--    that stories, planning input forms, and exported data all reflect only that region. 

Real project scenario

A retail client rolled out a single SAC sales planning model to 40 regional managers plus a small central finance team. Initially all users shared one model and one story, relying only on team-based folder security, which meant every regional manager could see and, worse, plan against every other region's numbers. During UAT a regional manager noticed competitor-adjacent region figures and escalated it as a data governance concern. The project team implemented a Data Access Control object driven by a nightly-refreshed mapping table (synced from the HR system's cost-center-to-manager assignments), secured on the Region and Cost Center dimensions of the planning model. They also discovered that the central finance team needed an 'all regions' view, which they solved by adding a wildcard/all-access row in the mapping table for those specific user IDs rather than exempting them from DAC entirely, keeping the audit trail consistent. Post-go-live, any new manager onboarded simply required a new row in the source mapping table, with no changes needed in SAC stories or models.

Common mistakes

• Confusing role-based object security (who can open a story) with row-level Data Access Control (which rows they see), leading to false confidence that a model is fully secured. • Manually maintaining a small hardcoded DAC mapping in SAC instead of a source-table-driven mapping, causing it to go stale as org structures change. • Not testing planning/write-back behavior separately from viewing behavior, assuming DAC restricts both identically. • Layering SAC DAC on top of a live connection's existing source-system authorization without checking for value-set mismatches, causing users to see blank data. • Testing security only with administrator accounts, which often bypass restrictions and give a false sense that security is working. • Forgetting that adding DAC to a model retroactively can break existing stories or bookmarks if users no longer have access to previously visible rows.

Best practices

• Drive Data Access Control mappings from a maintained source table or system-of-record attribute rather than manual entry, so security scales with organizational change. • Clearly separate responsibilities: object-level security via roles/teams for 'can open,' Data Access Control for 'which rows.' • For live-connected models, rely primarily on source-system authorizations and use SAC DAC only to fill gaps, avoiding double-filtering conflicts. • Explicitly test both display and planning/write-back behavior under DAC for representative user profiles before go-live. • Document DAC design (secured dimensions, mapping source, exemption logic) alongside the model so future changes do not silently break security. • Re-test DAC behavior after any structural change to the secured dimension or the model itself.

Interview angle

Interviewers assess whether a candidate understands that SAC security is layered: object-level (role/team) security plus row-level (Data Access Control) security, and that the two must be designed together, not interchangeably. Strong answers explain how DAC mapping sources work (manual, attribute-based, or table-driven), how DAC interacts differently with live connections versus imported models, and how to test row-level restrictions for both viewing and planning input using realistic non-admin test accounts.