Enterprise-Grade Implementation Guide
SAC Data Modeling: Design, Build & Optimize
Build production-ready SAP Analytics Cloud data models that maximize performance, governance, and reusability. Recent releases added live data access to Snowflake (Q1 2026) and Azure SQL (Q2 2026), My Metrics report subscriptions, and story file versions. Learn when to use live connections, import models, and planning models. Master dimension design, measure aggregation, and blending patterns for enterprise analytics at scale.
SAC Data Model Architecture Overview
SAP Analytics Cloud data models occupy a distinct layer in the modern analytics stack. SAC is not a data platform—it is a consumption and interaction layer. While your semantic layer (Datasphere) owns authoritative business definitions, SAC models consume those definitions and add consumption-specific logic for analytics use cases, planning, and simulation.
The Analytics Stack: Layers and Responsibilities
Understanding where SAC fits determines how you design models:
Semantic Layer (Datasphere)
- Business entity definitions
- Authoritative metrics & calculations
- Data governance & quality
- Row-level security policies
- Changes flow to all consumers
Consumption Layer (SAC)
- Analytics-specific aggregations
- Time-series & statistical functions
- Interactive planning & simulation
- Performance optimization per use case
- Story & dashboard logic
SAC Data Model Types: Decision Framework
Key Decision Factors: Evaluate model type based on data freshness requirements, volume constraints, analytical complexity, and governance needs. Live connections are the default choice; import models optimize for performance when live is insufficient.
Live Connection Models
Live models query Datasphere (or other sources) in real-time. Data is never stored in SAC; the platform acts as a query interface to authoritative sources.
When to Use Live
- Data freshness critical: Financial dashboards, operational monitoring, fraud detection. Users need data updated within hours or minutes.
- Large datasets: Acquired models have system limits and consume tenant storage; live connections leave the data in the source.
- Multi-tenant consistency: Multiple SAC tenants share the same semantic layer. Live connections prevent definition drift.
- Governance alignment: Changes to Datasphere definitions automatically flow to all SAC stories using live connections.
- Row-level security: Datasphere access controls enforce restrictions at query time, not at model load time.
Live Connection Challenges
- Query latency: Live queries are slower than in-memory. Each data-bound widget sends its own queries to Datasphere. Mitigation: fewer widgets per page, Top N, background or viewport loading, and Datasphere's InA/MDS cache.
- Source availability: Datasphere downtime breaks all live stories. Monitor the source and communicate maintenance windows to story owners.
- Limited analytics: Some advanced functions (complex statistics, ML scoring, custom aggregations) are harder in live queries. Pre-aggregate in Datasphere.
- Parameter complexity: Parameterized filters must be pushed server-side to maintain performance.
Import Models
Import models copy data into SAC's in-memory store. Data is loaded once (scheduled or manual) and optimized for fast analytics.
When to Use Import
- Performance critical: In-memory analytics required more than real-time freshness.
- Complex analytics: Advanced time-series functions, forecasting, simulation easier with imported data.
- Data blending: Combine Datasphere, BW, REST APIs, and local files in a single model.
- Import-only sources: Many SaaS and SQL sources (for example Salesforce, OData services, or SQL databases over JDBC) have import connections only.
- Medium datasets: Within SAC's import limits, acquired models are fast to query.
- Interactive planning: Users modify data (what-if scenarios). Imported data easier to manipulate.
Import Model Trade-offs
- Data staleness: Updated on schedule (hourly, daily, weekly). Not operationally current.
- Governance drift: Business logic duplicated across models. Changes to Datasphere require manual model updates.
- Storage cost: Each imported model consumes SAC memory. At scale, costs increase and performance degrades.
- Transformation complexity: Complex transformations belong in Datasphere, not SAC model builder.
Planning Models
Planning models are models with planning enabled: acquired models, or seamless planning models whose data lives in Datasphere. Users modify data to model scenarios, allocations, and forecasts.
When to Use Planning
- Interactive modification: Users enter budgets, forecasts, allocations as part of analytical process.
- Scenario versioning: Multiple versions (Actual vs. Budget vs. Forecast) with independent data.
- Allocation workflows: Top-down budgets distributed to regions, departments with review and approval.
- What-if modeling: Users simulate decisions and compare outcomes.
- Seamless planning with Datasphere: the planning model's data is stored in Datasphere (available since 2025).
Planning Best Practices
- Separate from reporting: Keep planning and analytical models distinct to avoid confusion about data source.
- Limit versions: 3–10 versions typically. Each additional version increases storage and complexity.
- Design grain carefully: Users work at this level (monthly? daily?). Coarser grain loses detail; finer grain slows interactivity.
- Implement locking: Data locks (open, restricted, or locked) with lock owners enforce the Draft → Submitted → Approved stages that calendar tasks drive.
- Model allocations: Top-down (corporate sets target, allocate to regions) or bottom-up (collect forecasts, roll up).
Data Modeling Fundamentals
Dimensions: Types and Hierarchies
Dimension Types in SAC
- Generic Dimensions: Standard categorical dimensions (Product, Customer, Channel). Include hierarchies matching how users think about the domain (Product Family → Product Line → SKU).
- Time Dimensions: Always explicitly model time. Use date fields (not text) so SAC can apply time functions. Hierarchies: Year → Quarter → Month → Day. Supplementary attributes: fiscal vs. calendar, weekday, holiday flags.
- Account/GL Dimensions: For financial models, structure must map to chart of accounts. Include aggregation properties (account type, cost center/profit center rules) for correct rollup.
- Organization Dimensions: Company structure, regions, sales territories. Hierarchies reflect reporting lines. Attributes: budget authority, P&L responsibility for planning workflows.
- Version Dimension: For planning models. Distinguishes Actual, Budget, Forecast, Prior Year. Keep simple (5–10 versions); don't use for every scenario variation.
Hierarchy Design Patterns
- Balanced vs. Unbalanced: Balanced hierarchies (all paths same depth) are simpler. Unbalanced (e.g., some products in retail not direct) are realistic. SAC handles both; unbalanced requires explicit modeling.
- Level-Based Hierarchies: Product Family → Product Line → SKU. Simplest, best performance. Recommended for most cases.
- Parent-Child Hierarchies: More flexible but harder to query. Use only when level-based won't work (irregular organizational structures).
- Multiple Hierarchies: A dimension can have multiple hierarchies. Product by Family (analytical) and by Sales Team (sales management). Include both.
- Slowly Changing Dimensions: Attributes that change over time (employee department). Decide whether to track history (accurately analyze past periods) or always show current (simpler, less storage).
Dimension Attributes: Strategic Selection
- Core Attributes: Uniquely identify members (Customer Number, Product SKU) or provide essential context (Customer Name, Product Description). Every dimension needs these.
- Analytical Attributes: Users filter or group by these (Customer Segment, Product Category, Department). Include the most commonly requested; don't try to include everything.
- Technical Attributes: Used internally but hidden from users (source system code, update timestamp, data quality flag).
- Data Types Matter: Dates as text can't be used in date functions. Numbers as text can't be summed. The type determines what operations users can perform.
Measures: Aggregation, Calculation, and Restriction
Measure Aggregation Rules
Measures aggregate automatically when users slice dimensions. Configure correct rules to ensure totals are meaningful:
- Default Sum: Most transaction measures (orders, invoices). Users drill down or filter; totals roll up as expected.
- Average/Weighted Average: Cost per unit, profit margin, return rate. Mark these explicitly so aggregation respects semantics.
- Exception Aggregation: Maximum Weekly Temperature, Current Inventory Balance need special handling. When aggregating week to month, want max of week values, not sum.
- Dimension-Specific Rules: A measure sums across product but averages across customer. Configure different aggregation per dimension when necessary.
Calculated and Restricted Measures
- Base Measures: Directly from source data (Order Amount, Unit Cost, Quantity Ordered).
- Calculated Measures: Derived from formulas (Gross Profit = Amount - Cost; Profit Margin = Gross Profit / Amount; YTD Sales = running sum).
- Restricted Measures: Base or calculated measures filtered to specific values. "Domestic Sales" = Sales restricted to Country='USA'. Applied automatically; users don't enter formulas.
- Version-Restricted Measures: In planning models, "Budget Amount" = Amount where Version='Budget'.
- Currency Conversion: In models with measures, define conversion measures that apply rates from a currency conversion table. Define the conversion method explicitly (source and target currency, rate type such as average or closing rate).
Advanced Measure Types
- Year-to-Date (YTD): Running accumulation from period start. Essential for financial analysis; automatically adjusts as users filter time periods.
- Prior-Year Comparison: Compares current to same period last year. SAC shifts time context automatically.
- Growth and Variance: Express change over time. Define precisely: absolute growth (current - prior) or percentage ((current - prior) / prior)?
- Forecasting Integration: Smart Predict time-series forecasts can seed a planning version as a starting point; they are not recalculated inside measures as users interact with stories.
Connection and Data Patterns
Live Connection Design
Building a live connection to Datasphere or HANA requires strategic choices:
Query Design
- Scope carefully: Include essential dimensions and measures. Larger scope = slower queries.
- Pre-filter: If not all data is needed, filter at connection level (e.g., "only current fiscal year").
- Aggregation strategy: Live queries benefit from pre-aggregated Datasphere views. Most SAC analyses at monthly grain? Have Datasphere provide monthly aggregates.
- Parameterization: Can users filter (e.g., "my region")? Parameterized server-side filtering is much faster than returning all data.
Caching and Performance
- Caching: Progressive chart rendering (an administrator setting) shows charts faster when a story is reopened within an hour, and live Datasphere queries use Datasphere's InA/MDS cache, which is on by default.
- Fewer widgets: Each data-bound widget sends its own queries, so pages with fewer widgets load faster than crowded ones.
- Bookmark strategy: Save frequently used filter states as bookmarks so users don't rebuild them; bookmarks save state, not query results.
- Datasphere health: If Datasphere is unavailable, live stories fail; monitor the source and plan maintenance windows outside reporting peaks.
Import and Snapshot Strategies
For imported models, balance freshness against performance:
- Scheduled Refresh: Most common. Refresh on schedule (daily, twice daily, weekly) aligned with business rhythm. Financial closing at month-end? Refresh after closing completes.
- Incremental Import: For large models, import only new data, for example with SAC's incremental load filter and the Append import method (Update, Append, Clean and replace selected version data, and Clean and replace subset of data are the available methods), instead of reloading everything.
- Snapshot Retention: For "as of" reporting, append each load with a snapshot date (or copy it to a version) instead of overwriting, and set a retention rule because storage grows.
- Optimization: Keep imported models lean: drop unused columns and dimensions during data preparation.
Data Blending Patterns
SAC blends multiple models or sources in a single analysis:
- Live + Planning: Show live actuals next to plan data, either by linking models in a story where the sources support blending or, more simply, with seamless planning and external live versions so actuals and plan sit in one model.
- Cross-Source: Combine Datasphere, HANA, and external files (CSV) in one story. Blending links models at query time through common dimensions; support varies by source type.
- Grain Mismatch: If blending different grain (daily vs. monthly), aggregation to common level before join. Document clearly.
- Blend Complexity Risk: Powerful but fragile. Complex blends break when data changes. If blend is complex, consider whether logic should move to Datasphere or split into simpler models.
Planning Model Deep Dive
Version Structure and Data Segregation
Planning models use versions to separate planning scenarios. Common patterns:
Version Structures
- Simple (3 versions): Actual / Budget / Forecast. Separates history from plan. Intuitive and easy to manage.
- Detailed (5–8): Actual / Conservative / Base / Optimistic / Alternative Strategy. Granular scenarios. Requires discipline—too many versions create confusion.
- Period-Based: Plan2025_Jan, Plan2025_Feb track forecast evolution. Useful for forecast accuracy analysis but generates many versions.
- Rule: Keep 3–10 versions. More increases storage, complexity, and user confusion.
Seamless Planning with Datasphere (since 2025)
- Storage: The planning model's data is stored in a Datasphere space, so there is no separate write-back step.
- Consistency: All downstream analytics see same planning data.
- Governance: Plan data in Datasphere is governed by the space's permissions like any other Datasphere data, while SAC model security governs planning.
- Integration: Other Datasphere consumers (views, analytic models, data products) use plan data without manual export or import, and external live versions bring Datasphere actuals into the model (Q4 2025).
Locking and Approval Workflows
Hierarchical Status-Based Locking
Design locking to match your planning process:
- Status Flow: Calendar tasks move work through Draft → Submitted → Approved, and data locks (open, restricted, locked) enforce each stage on the data.
- Hierarchical Locks: Department budget locked once submitted, but division-level not locked until all departments submitted. Prevents modification of locked data.
- Lock Owners: Assign data locking owners per entity so the right controller can reopen a submitted budget for adjustments, while department managers cannot.
- Audit Trail: Switch on data audit so SAC logs who changed which values and when; planning is contentious (resource allocation), and clear trails prevent disputes.
Allocations and Distribution
Common Allocation Patterns
- Top-Down: Corporate sets total revenue target; allocation formula distributes to regions based on historical market share. Regions accept, negotiate, or adjust.
- Bottom-Up: Each region provides forecast; totals roll up to corporate. Corporate reviews and returns feedback if unrealistic.
- Pro-Rata: Allocate corporate overhead to business units in proportion to revenue. Automate so revenue changes automatically adjust costs.
- Configurable Allocations: Different allocation bases for different measures. Auditable (show what was allocated and why).
Performance Optimization
Model Sizing and Memory Management
Acquired models have system limits and consume tenant storage. Use this guidance:
- Small models: Fast regardless of query pattern. No special optimization needed.
- Medium models: Fast with good design. Optimize by removing unnecessary dimensions and columns.
- Large models: Require careful design. Pre-aggregate upstream for common query patterns, filter at load time, and consider splitting by period or domain.
- Very large data: Strongly consider live connections or seamless planning with live versions instead of importing.
Query Optimization and Aggregates
Pre-Aggregation Upstream
Summary stories perform better when they query pre-aggregated data:
- Aggregate Views: Build aggregated views at common grain (monthly instead of daily, company instead of department) in Datasphere or the source, alongside the detailed data.
- Deliberate Routing: Point summary stories at the aggregated models and detail stories at the detailed ones, and document which is which.
- Selective Creation: Focus on aggregates for queries users actually run (high-frequency, slower queries). Creating aggregates for every combination wasteful.
Splitting Models and Storage
- Time Partitioning: Separate models by year or period. Queries within one year faster than across decades. Users switch between models as needed.
- Storage Engine: SAC manages compression and storage internally, so focus on what you control: model scope, granularity, and load filters.
- Measure Before Splitting: Split models only after Performance Insights or user feedback shows a real problem, because every split adds maintenance.
Recent SAC Features: Story File Versions, My Metrics, and Live Snowflake Access
Three recent capabilities affect data modeling strategy and implementation patterns, mostly by clarifying what belongs in the model and what does not:
Story File Versions
Since the Q1 2026 release, designers can save versions of an optimized story, review them, restore an earlier one, or delete versions. File versions are backups of a story's design, not a scenario or approval feature, so scenario logic still belongs in the data model:
Implementation Pattern: Multi-Scenario Planning
- Model Design: Create planning models with explicit versions (Actual, Budget, Forecast, Best-Case, Worst-Case). With seamless planning, all versions are stored in the same Datasphere-backed model, distinguished by the version dimension.
- Story Setup: Build one story that shows several planning versions side by side (Actual vs. Budget vs. Forecast) through the version dimension and variance measures; users switch versions with filters, not with story file versions.
- Approval Workflow: Run approvals through calendar review tasks and data locking; story file versions carry no approval status.
- Practical Benefit: Saving a file version before a major redesign replaces copies named like "Story_
Budget_ v1_ FINAL_ APPROVED" and makes rollbacks quick. - Data Model Impact: Keep versioning logic in the data model (the version dimension), not in story copies or story file versions.
Implementation Pattern: Comparison Story Template
- Model Setup: Create derived measures that calculate version variance: Budget vs. Actual variance, Forecast Accuracy (Forecast vs. Actual), YoY % change.
- Story Template: Build a template story where users pick the two versions to compare (for example with a version filter or input controls); variance measures calculate the difference.
- Governance: Save a file version of the template before changing variance logic so you can roll back, and document each change for the teams that reuse the template.
- Reusability: Template scales to dozens of stories comparing different dimensions with consistent methodology.
My Metrics for Planning KPIs
My Metrics (Q4 2025) lets users collect KPIs from story charts into personal or shared lists; since Q1 2026 they can subscribe to scheduled metrics reports by email or in-app notification, and Q2 2026 added Microsoft Teams delivery. My Metrics tracks existing chart metrics and is not a data-entry tool, so personal goals still need a planning model:
Implementation Pattern: Personal Planning Workspace
- Model Foundation: Create a dedicated "Personal Goals" planning model. Dimensions: User (linked to employee master), Goal Category, Metric Type, Fiscal Period. Measures: Target Value, Actual Value, Variance, Achievement %.
- Data Governance: Use data access control so each user writes only their own goals and managers read their team's; aggregated views give executives the consolidated picture.
- Story Pattern: Build a "My Goals" story on that model with achievement gauges, trend lines, and comments; users add its key charts to their lists in My Metrics.
- Planning Integration: Personal goals roll up to departmental/org goals. Planning model contains aggregation logic: sum personal targets to team target, compare to org target. Identifies gaps.
- Practical Setup: Users enter targets and updates in a planning-enabled table in the "My Goals" story; My Metrics then shows the resulting KPIs next to the other metrics they follow.
Live Snowflake Access and Model Setup
Since the Q1 2026 release, SAC's live data access reaches Snowflake (alongside Google BigQuery and, since Q2 2026, Azure SQL) through the data access agent on tenants running on SAP HANA Cloud. Snowflake views become read-only live versions in SAC models:
Implementation Pattern: Live Snowflake Data in SAC
- Architecture Decision: If governed analytics data already lives in Snowflake and its views are modest in size, read it live from SAC instead of copying it. SAP currently advises against live access to Snowflake tables above one million rows; import or route larger domains through Datasphere.
- Semantic Model Setup: Datasphere has no remote tables on Snowflake: bring Snowflake data into Datasphere with replication flows (initial load only) or as data products shared back through BDC Connect for Snowflake, then let SAC consume the Datasphere model. Use SAC's Snowflake live connection for domains whose definitions the Snowflake team governs.
- Performance Optimization: SAC reads regular Snowflake views, not semantic views; keep them narrow and pre-aggregated, and use Snowflake clustering for the filters stories apply most.
- Security and Governance: The connection authenticates as one Snowflake user (key-pair authentication), so that user's Snowflake role limits what SAC can read; restrict individual SAC users with model security such as data access control. Live versions are read at runtime and not replicated into SAC.
- Practical Workflow: Snowflake admin: creates a read-only user with key-pair authentication and grants it the analytics views. SAC admin: enables the data access agent and creates the Snowflake connection. Modeler: builds the model from a view and adds live versions. Analysts and planners: use stories on that model.
- Cost Implications: Snowflake charges compute credits for analytics queries. Monitor query patterns; if queries expensive or slow, consider importing subset to SAC or materializing aggregate tables in Snowflake.
Practical Implementation: Multi-Source Blending with Snowflake + SAP
Scenario: Your org uses Snowflake for cloud SaaS data (Salesforce, Workday, third-party), SAP for transactional data (orders, GL, materials). Need unified analytics.
- Data Architecture:
- Datasphere semantic layer owns business definitions (Customer, Product, Period, Account).
- Snowflake data for cloud SaaS (customer engagement, workforce costs) reaches Datasphere through replication flows (initial load only) or as data products shared back through BDC Connect for Snowflake.
- Datasphere ingests SAP data for transactions (Orders, GL, Inventory).
- Datasphere joins these sources at the semantic level (e.g., Customer from Salesforce matched to Customer from S/4HANA).
- SAC Model Strategy:
- Live connection to Datasphere model includes all joined data.
- If performance insufficient, create import model that snapshots Datasphere data (e.g., nightly refresh).
- If one Snowflake domain must stay live and its views are modest in size, give it its own SAC model with a Snowflake live version and keep cross-domain joins in Datasphere.
- Common Pitfall: Connecting SAC live to raw Snowflake views and to SAP sources separately, then stitching them together in stories. This creates semantic inconsistency (two definitions of "Customer"). Instead: let Datasphere own the semantic join, then SAC consumes unified model.
Implementation Roadmap: Four-Phase Approach
Phase 1: Design and Governance (Weeks 1–2)
- Stakeholder Alignment: Define analytics requirements with business stakeholders. What are the key analyses? What dimensions matter for drilling down? Validate against actual user workflows (run shadowing sessions, observe spreadsheet analyses).
- Model Architecture Decision: For each planned model, decide live vs. import vs. planning. Document business justification: Is data freshness critical (live)? Is volume massive (live)? Is performance priority (import)? Is this planning/simulation (planning)?
- Source Assessment: Evaluate source data quality, freshness, and availability. Create data profile: row counts, null percentages, cardinality of dimensions. If using Datasphere, confirm semantic definitions are in place and accurate.
- Dimension and Measure Framework: Design dimensions iteratively with stakeholders. Walk through sample analyses: "Show me sales by region, product, month. How do you drill from region to territory to store?" Confirm hierarchies. Sketch measure calculations: revenue (sum), margin %, customer count, blended cost (weighted avg).
- Governance Checklist: Who owns the model long-term? Who approves new dimensions or measures? What naming conventions apply? Document decision rules: When is a metric a measure vs. a calculated column? How do we version the model?
Phase 2: Build Core Models (Weeks 3–5)
- Development Environment: Set up SAC development tenant with source connections (Datasphere, BW, HANA). Configure separate DEV and TEST environments if possible; avoids stepping on other teams' work.
- Dimension Development: Build dimensions with hierarchies and attributes. For Time dimension: always explicit hierarchies (Year → Quarter → Month → Day). For Product: include rollup level attributes (Product Family, Category). Test drill-down navigation. Verify grain (e.g., Product is unique within dimension, not repeated). Validate cardinality early: very large dimensions slow stories and planning.
- Measure Implementation: Create base measures (simple sums, counts), calculated measures (Revenue - Cost), and restricted measures (YTD Revenue; Revenue for approved orders only). Test aggregation rules: Does revenue sum across months? Does margin average? Verify subtotals and grandtotals match calculations (spot-check 10 manual examples).
- Model Connection Setup: For live connections: test latency with production load. For import models: run initial load with full data; measure size and refresh time. Set automated refresh schedule (nightly, hourly?). Monitor refresh failures; set alerting if refresh misses SLA.
- Row-Level Security: Implement data access controls (e.g., Sales reps see only their territory). Test with sample users from each security group. Document: "Rep in EMEA region sees orders for EMEA only." Verify no data leakage across security boundaries.
Phase 3: Test and Optimize (Weeks 6–7)
- Data Accuracy: Reconcile SAC model data to source systems. Pick 5 metrics users care about most. Run SAC query, export result, compare to source report. Ensure totals match exactly. If variance, investigate: Is it a calculation difference? A filter difference? A data grain issue? Document every variance reason.
- Performance Baseline: Load full production data volume. Measure model size (GB). Test common queries: Summary by region (should be instant). Drill to detail (how long?). If any query exceeds 5 seconds, optimize (add aggregates, simplify blend, reduce data grain).
- Concurrency Testing: Simulate realistic user load. If story will serve 30 concurrent users, test with 30 simultaneous queries. Measure response time degradation. Document acceptable response time SLA: "Under 3 seconds for regional summary, under 10 seconds for detailed drill."
- Business User Validation: Conduct UAT with 5-10 power users. Provide pre-written analysis scenarios: "Show me Q1 revenue by product family. Drill into the top family and compare to Q1 last year." Collect feedback on usability, data correctness, dimension names. Iterate if needed.
- Documentation: Create data dictionary: Dimension definitions (what does "Product Family" mean?), Hierarchy structure (how does it roll up?), Measure definitions with formula, Data grain (fact table is at Order Line level), Source-to-model mapping (where does Product Dimension come from?).
Phase 4: Deploy and Operate (Weeks 8+)
- Production Deployment: Promote models to production SAC environment. Confirm access controls and row-level security active.
- Refresh Automation: For imported models, operationalize refresh schedule. Monitor refresh health and data staleness.
- Story Development: Build optimized stories on the models, adding scripting only where needed; the classic experience, including analytic applications, was retired at the end of Q2 2026.
- Training and Adoption: Train business users on model structure, how to interpret data, common analysis patterns. Gather feedback.
- Ongoing Operations: Monitor model usage, query performance, data freshness. Adjust refresh schedules, aggregates, or connections based on performance.
Pre-Production Readiness Checklist
Before deploying SAC models to production, verify these 12 critical items:
- Architecture Decision Documented: For each model, explicit decision (import/live/planning) with business justification. Stakeholder agreement.
- Source Data Validated: Connections tested; data quality verified. Datasphere semantic definitions in place and operating.
- Dimension Hierarchies Finalized: All dimensions have at least one hierarchy. Tested drill-down with business users; feels natural.
- Measure Aggregation Tested: All measures have correct aggregation rules. Tested behavior; totals and subtotals correct.
- Restricted/Calculated Measures Defined: All required restricted measures (currency-specific, version-specific) and calculated measures (YTD, growth, variance) implemented.
- Performance Baseline Established: Model size documented. Key query patterns tested; response times measured and acceptable. Slow queries optimized.
- 7. Data Quality Validation Complete: Sample data reviewed for accuracy. Spot-checks of key metrics verified. Reconciliation to ledger totals.
- 8. Row-Level Security Configured: If using access controls or version restrictions, tested with sample users. Each user sees appropriate data.
- 9. Model Documentation Published: Data dictionary with all definitions. Data grain documented. Source-to-model mapping for modifications.
- 10. Refresh/Load Process Operationalized: Scheduled refresh set and monitored (import). Live availability tested (live). Versioning and locking configured (planning).
- 11. Backup and Recovery Configured: Content export packages (Content Network or file export) in place, and story file versions saved before major changes. Recovery tested.
- 12. Business User Training Completed: Target users trained on structure, interpretation, analysis patterns. Feedback collected and incorporated.
Common Pitfalls and Prevention
Pitfall: Using Import When Live Should Be Used
The Problem: Teams import large fact tables (millions of rows) that could be queried live. Imported model requires daily refresh, is slow, and consumes significant storage. Live connection would be faster and current.
Prevention: For large models, evaluate live first. Prototype both; benchmark data freshness, refresh time, query performance, storage cost. Document decision.
Pitfall: Weak Dimension Design
The Problem: Dimensions created hastily with minimal attributes. As users request additional slicing (by region, family, type), attributes added ad-hoc, making dimensions confusing. Hierarchies don't match analytical patterns.
Prevention: Spend time upfront understanding user analysis. What are natural groupings? What drill-down dimensions matter? Design to match user thinking. Rough hierarchy and attributes, user-validated up front, faster than iterating weak design repeatedly.
Pitfall: Aggregation Rule Surprises
The Problem: Measure created with default sum aggregation. Users discover later that across certain dimensions, totals are wrong. Profit margins sum instead of average; inventory balances sum instead of latest. Reports look credible until scrutinized.
Prevention: For every measure, explicitly decide aggregation rule and document it. If uncertain, test before publishing. A measure that sums when it should average is worse than no measure.
Pitfall: Planning Model Complexity Underestimated
The Problem: Planning model built with 10+ versions, inconsistent data types, weak locking, no approval workflow. Users submit budgets but don't know if approved. Budget changes continue after submission. Chaos.
Prevention: Plan planning design with the people running the actual planning process. Understand their workflow first. Design simplicity: fewer versions, clear statuses, lockdown preventing unintended changes. Test full workflow end-to-end with users before going live.
Pitfall: Blend Complexity Without Documentation
The Problem: Story blends three sources (Datasphere live, imported forecast, Excel file). Blend logic complex (different grain, multiple joins). New analysts can't understand or modify story. When data changes, blend breaks.
Prevention: If story uses blending, document why. "Actual from Datasphere blended with Budget from planning model using Order and Time dimensions" sounds simple but critical for maintainability. If blend complex, move logic upstream to Datasphere or split into simpler models.
Pitfall: Inadequate Performance Testing
The Problem: Model performs well with few users in development. After launch, with many concurrent users, performance degrades. Queries taking 2 seconds now take 20. Stories disabled because too slow.
Prevention: Performance test before launch with realistic data volume and concurrency. If model supports 50 concurrent users, test with 50 concurrent queries. If has year's data, load full year. Measure and accept or optimize baseline before publishing.
Pitfall: Live Model Without Source Governance (Q1 2026)
The Problem: Teams adopt SAC's live Snowflake access (Q1 2026) to avoid data copies. But Snowflake source data is not governed; definitions change without coordination. SAC stories break when Snowflake schema changes. Reconciliation impossible because upstream definitions are unclear.
Prevention: Before building a live connection to an external SQL source (Snowflake, Google BigQuery, Azure SQL), agree who owns the business definitions. If the semantic model must live in Datasphere, bring Snowflake data in through replication flows or BDC Connect data products and let SAC consume Datasphere; use SAC's Snowflake live connection only for domains whose definitions the Snowflake team governs and versions.
Pitfall: Treating Story File Versions as Scenarios (Q1 2026)
The Problem: Teams treat story file versions (Q1 2026) as scenario management. But a file version is a backup of a story's design, not of its data: restoring last month's story version still shows today's data, and which planning version a story displays depends on its filters.
Prevention: Use story file versions for design rollbacks only. Data versioning belongs in the data model (the version dimension), and approvals belong in calendar tasks and data locks. Document which planning version each story shows, for example "the board story always displays the Approved version". Keep these layers separate.
Key Features and Capabilities Reference
Model Types Quick Reference
| Feature | Live Connection | Import Model | Planning Model |
|---|---|---|---|
| Data Location | Datasphere/Source | SAC in-memory | SAC, or a Datasphere space with seamless planning |
| Data Freshness | Real-time | Scheduled refresh | Current (user-modified) |
| Performance | Slower (queries source) | Fast (in-memory) | Fast (in-memory) |
| Blending | Limited | Yes, with other models/sources | With other models |
| User Modification | Read-only | Read-only | Yes, with versioning & locking |
| Datasphere Sync | Automatic (live) | On refresh | Stored in Datasphere with seamless planning (since 2025) |
Dimension Types Quick Reference
- Generic: Product, Customer, Channel. Include hierarchies (Family → Line → SKU).
- Time: Always explicit. Hierarchies: Year → Quarter → Month → Day. Attributes: fiscal vs. calendar, weekday, holiday.
- Account/GL: Must map to chart of accounts. Aggregation properties for correct rollup.
- Organization: Company, regions, territories. Hierarchies match reporting lines. Attributes: budget authority, P&L responsibility.
- Version: Planning models only. Actual, Budget, Forecast. Keep 3–10 versions.
Measure Types Quick Reference
- Base Measures: From source data. Order Amount, Unit Cost, Quantity Ordered.
- Calculated Measures: From formulas. Gross Profit (Amount - Cost), Profit Margin, YTD Sales.
- Restricted Measures: Base or calculated filtered to values. Domestic Sales (Country='USA'). Version-restricted in planning.
- Time-Series Measures: YTD, Prior-Year Comparison, Growth, Variance, Trend, Forecast.
- Aggregation Rules: Sum (default), Average, Max/Min, Exception (varies by dimension).
Connection Sources Supported
- Datasphere (Recommended): Live connections to semantic layer. Real-time, governance-aligned, multi-tenant consistency.
- BW/4HANA: Live connections to Business Warehouse. Transactional analytics.
- HANA Cloud: Live connections. Real-time, high-performance source.
- S/4HANA: Live connections. Embedded analytics in ERP.
- SQL Sources and Blending: Live data access to Google BigQuery, Snowflake (Q1 2026), and Azure SQL (Q2 2026) as read-only live versions; import connections for other sources (OData, SQL databases, files); blending combines models in a story where the sources support it.
Planning Capabilities Summary
- Model Types: New model type with measures (recommended; account dimension optional) and classic account model.
- Versioning: Separate data for Actual, Budget, Forecast, etc. Keep 3–10 versions.
- Locking: Data locks (open, restricted, locked) with lock owners; calendar tasks drive Draft → Submitted → Approved.
- Allocations: Top-down (corporate to regions), bottom-up (regional forecasts to corporate), pro-rata (overhead allocation).
- Seamless Planning: Planning model data stored in Datasphere (since 2025); external live versions read Datasphere actuals (Q4 2025).
- Unified Experience: Optimized stories combine story design and scripting; analytic applications were retired with the classic experience at the end of Q2 2026.
Performance Optimization Techniques
- Model Sizing: Keep acquired models within SAC's limits and lean; for very large data, prefer live connections or seamless planning with live versions.
- Pre-Aggregation: Aggregated views (monthly vs. daily) built upstream for summary stories.
- Partitioning: Time-based separation (year per model). Queries within one year faster than across decades.
- Loading: Background or viewport loading in optimized stories; avoid charts with more than 500 data points; use Top N.
- Query Optimization: Fewer data-bound widgets per page, server-side filtering with variables, and the Performance Insights tool to find slow widgets.
Where Next
Continue your learning