SAP SAC Security: Consultant Troubleshooting and Production Guide

Typical project situations include: Regional planners shared one planning model. Story access was correct, but without model-level data restrictions they could see other regions. Data Access Control aligned visibility with organizational responsibility.

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.

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.

SAC authorization has several layers. Platform roles determine which capabilities a user can use. Teams simplify assignment to groups of users. Model-level permissions control access to content, while Data Access Control can restrict data values inside a model.

The common mistake is solving data security only with folder permissions. A user may have legitimate access to a story but should still see only one region or company. Data access must therefore be modeled at the data layer where appropriate.

Planning adds write security. A user may be allowed to read forecast data but write only their cost center or version. Test read and write behavior separately.

Connections and live-source authorization also matter. In live scenarios the source system can remain authoritative for data authorization; do not duplicate or weaken security accidentally in SAC.

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.

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

Use evidence from the relevant configuration, master data, transaction/document status, integration monitoring and application logs rather than relying on the UI symptom alone. Explain SAC roles, teams, content permissions and model data access as separate layers.

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.

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.

Resolve the issue at the owning configuration/process layer, then validate the end-to-end business outcome, integration state and regression path.

A common wrong direction is: Assigning permissions directly to individual users instead of teams, causing unmanageable sprawl as staff change. This is unsafe because it can bypass the process, integration or governance condition that produced the issue. Reproduce the scenario, isolate the layer and validate the complete business result before applying a workaround.

Primary ownership sits with the SAC_DATASPHERE consultant for process/configuration semantics, with integration, security, development or platform teams engaged when evidence crosses those boundaries. Explain SAC roles, teams, content permissions and model data access as separate layers.

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.

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.