Concept card

SAP Analytics Cloud (SAC)

As of 2026-10-10

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is SAP Analytics Cloud (SAC)?

What it is and why it matters

SAP Analytics Cloud is SAP's single surface for business intelligence, planning, and predictive analytics, and it is the consumption layer that sits on top of almost every Datasphere or BDC deployment. Business users touch SAC directly; it is also, unglamorously, where most "why is the dashboard slow" tickets land, because the boundary between SAC and its data source is where architectural decisions about push-down and concurrency actually bite. Understanding that boundary, not just building stories, is what separates a senior SAC architect from someone who can only drag fields onto a canvas.

How it works: three connection modes

SAC stories can be built on three distinct connection modes, and the choice is the single biggest performance and cost lever in any deployment. Live connection queries Datasphere or HANA Cloud directly on every render — every chart is one or more federated SQL queries pushed down to the source engine. That gives real-time freshness at the price of latency, typically 100-500 ms at the median, and a practical concurrency ceiling of around 200 simultaneous ad-hoc users per Analytic Model before tail latency starts to degrade. Import connection instead pulls data into SAC's own in-memory cache on a schedule; stories then query that cache rather than the source, which brings median latency under 100 ms and lifts the concurrency ceiling into the thousands of users per model. The cost is staleness — data is only as fresh as the last refresh, typically every one to twenty-four hours — and a cache size that is bounded, roughly 5 GB per model by default, though raisable. Hybrid connections blend the two: live for the volatile slice of the data, import for the stable historical slice, joined at story level.

When to use each — the trade-offs

The decision is rarely "which is better" and almost always "which trade-off does this audience tolerate." A finance controller checking a real-time operational number cares about freshness more than raw speed, so live connection is the right call, accepting the latency and the lower concurrency ceiling. An executive dashboard viewed by two thousand people once a week cares about instant load time far more than second-by-second freshness — import connection is the obvious fit, and the staleness window is invisible to that audience. Once a deployment crosses roughly two hundred concurrent users while also needing some freshness, hybrid becomes the default pattern for most enterprise rollouts: keep the fast-changing numbers live, cache the historical baseline. The anti-pattern is picking live connection by default because it "feels more correct" — for a wide-audience dashboard that single decision can be the entire root cause of a concurrency-driven slowdown that later gets misdiagnosed as a Datasphere performance problem.

SAC versus Power BI versus Tableau is a comparison that recurs in almost every BI front-end shortlist, but the meaningful trade-off is not visualisation quality — SAC is the only one of the three with a native, write-back planning engine built into the same tool and licence family. Choosing SAC purely for BI when the organisation has no SAP-centric semantic layer to consume is a weaker case than choosing it specifically because Datasphere Analytic Models already exist and planning is on the roadmap.

The SAC-Datasphere pairing pattern

The canonical tier-one architecture uses Datasphere Analytic Models as the governed semantic layer and SAC stories purely as the rendering surface. Every Analytic Model carries the business logic that must stay consistent everywhere — currency conversion, restricted measures, hierarchy semantics, rows protected by Data Access Controls — and SAC stories simply pick from what the model exposes. The architectural rule that experienced teams enforce without exception: never point an SAC story at a raw Datasphere SQL view; wrap it in an Analytic Model first. The reason is not a stylistic preference, it is consistency. If five different stories each reimplement currency conversion or a restricted-measure filter independently, they will eventually disagree, and nobody will be able to explain why two "identical" numbers on two dashboards do not match.

Pitfalls and anti-patterns

Beyond the raw-view anti-pattern, the two recurring failures are story sprawl and silent staleness. Story sprawl happens when every analyst builds a personal story instead of consuming a governed one, so the same metric gets computed five slightly different ways across the tenant — a governance failure disguised as self-service enablement. Silent staleness happens when an import connection's refresh schedule quietly breaks, a failed job or an expired credential, and nobody notices until a business user flags that "the numbers look wrong"; treating the refresh job itself as monitored, alerting infrastructure rather than a fire-and-forget schedule is the fix. A third pitfall is under-provisioning for concurrency: teams size an Analytic Model for the pilot's ten users and never revisit the connection-mode decision as the rollout scales into the hundreds, which is exactly the point at which live connection's roughly 200-user ceiling turns from a footnote into an incident.

Joule's 'just ask' layer in SAC, and its new operational prerequisite

Joule's analytical-insights capability in SAP Analytics Cloud is driven by a 'just ask' feature that indexes supported SAC models plus any SAP Datasphere analytic models that are part of a BDC formation — meaning the natural-language question a business user types into Joule is answered by reading the same governed semantic layer this card argues every SAC story should be built on, not a separate AI-specific copy of the data (help.sap.com; community.sap.com, 2026). That is the concrete reason the architectural rule in this card's body — never expose a raw Datasphere view directly to SAC, always wrap it in an Analytic Model — now has AI-consumption stakes as well as BI-consumption stakes: a story built on a raw view is invisible or inconsistent to Joule's 'just ask' indexing in exactly the way it is invisible or inconsistent to a second human-built story.

The operational detail worth flagging to any client running or planning this integration: the Joule 2506 release introduced a breaking prerequisite requiring SAP Build Work Zone to provision and synchronise users and roles from SAC to Work Zone for the conversational-analytics integration to keep working (SAP Community, 2026). This is exactly the kind of dependency this card's 'Early Adopter features sold as GA' pitfall (see C024) warns about — a scoping conversation that priced 'Joule in SAC' without checking whether the client already runs Work Zone, or whether provisioning it is in scope, will discover the gap after go-live rather than during the estimate. Confirm Work Zone's presence, or its cost to add, before quoting a fixed-price Joule-in-SAC engagement.

On the predictive side this card covers (Smart Predict for citizen-data-scientist workflows, Databricks for complex ML), the broader Business AI Platform now also carries SAP's tabular foundation models — SAP-RPT-1.6 and RPT-1.6-large are the current generation on generative AI hub as of September 2026, alongside a managed Tabular Orchestration workflow and an RPT Playground API (up to 1,000 requests/hour) for experimentation. These sit architecturally between Smart Predict's simplicity and Databricks' full ML-engineering weight: an in-context-learning model that predicts from a labelled table at inference time, no training step, which is worth naming as a third predictive option in a scoping conversation rather than defaulting straight to the Smart-Predict-or-Databricks binary this card currently frames — the right choice depends on whether the client's predictive need is closer to 'quick, tabular, no ML team' (RPT) or 'governed, repeatable, citizen-friendly inside SAC' (Smart Predict) or 'custom, large-scale, ML-team-owned' (Databricks).

What changed since late September 2026

28 September 2026 — Excel add-in 2026.21 (SAP primary documentation). Currency conversion can now be defined and managed directly in the workbook: a new Add Currency Conversion action on the Measure or Structure dimension, available when the underlying SAC model supports currency conversion, produces a calculated member (source member, target currency, category, date) usable like any other measure. This reinforces the card's point: the conversion logic must live in the model, because the add-in now reads it from there.
28 September 2026 — same release. A new, opt-in Enable advanced data retrieval (incl. optimized retrieval) setting uses data clustering to reduce the risk of exceeding server limits on large workbooks. It is not enabled by default so that existing workbooks are unaffected.

Update of 10 October 2026

8 Oct 2026 - SAC Planning upgrade path (ERP Today, SAP primary source not read). Following SAP Connect, SAC Planning customers can upgrade to SAP Enterprise Planning; Group Reporting customers can add the Financial Consolidation Assistant or upgrade; BPC and BFC migration services are planned from Q1 2027, and EPM applications are packaged with BDC core capacity. For a SAC Planning client this is a dated option, not a reason to replatform now: keep the current planning model stable and put the Q1 2027 deliverables in the decision calendar.
8 Oct 2026 - enablement. SAP Community announced that the SAC video tutorials were fully updated for Horizon.
What did not change. The sources reviewed contain no Connect-specific SAC announcement, so the Excel add-in and Datasphere guidance above stands.

Why it matters

Live connections cap at roughly 200 simultaneous ad-hoc users per Analytic Model before tail latency degrades — past that threshold, Import or Hybrid becomes necessary.
Import mode trades freshness for scale (thousands of users, sub-100ms) but leaves data stale between refreshes, typically 1-24 hours — wrong for real-time governed reporting.
Skipping the Analytic Model wrapper breaks the consistency of currency conversion, restrictions, and calculated measures that SAC stories depend on.

Key points

Three modes: Live (push-down, < 200 user, real-time) · Import (cache, 1000s user, stale) · Hybrid (both).
Always wrap raw Datasphere views in an Analytic Model before exposing to SAC.
Planning is the SAP differentiator — write-back, version control, audit, top-down/bottom-up reconciliation.
Predictive: Smart Predict for citizen-data-scientist + simple; Databricks for data-scientist + complex ML.
DAC at Datasphere is the row-security source of truth — reaches SAC + Joule + Delta + OData.
Concurrency cap on Live mode: ~200 simultaneous; hybrid above that.
Joule reads SAC story metadata + Datasphere Analytic Models for natural-language Q&A with citations.
SAC bills separately from Datasphere CU (per-named-user / per-concurrent-user model).

Common pitfalls

Pricing Joule-in-SAC without checking Work Zone — Signal: A fixed-price Joule conversational-analytics engagement is quoted, and the client doesn't run SAP Build Work Zone — the 2506 breaking prerequisite surfaces as a change request after go-live. Fix: Confirm Work Zone's presence, or its provisioning cost, before quoting a fixed-price Joule-in-SAC engagement.
Letting Joule index a story built on a raw Datasphere view — Signal: Joule's 'just ask' answers are inconsistent or incomplete because the underlying story skipped the Analytic Model wrapper — the same anti-pattern this card warns about for human-built stories now degrades the AI layer too. Fix: Apply the Analytic-Model-first rule universally — it is now an AI-consumption requirement, not just a BI-governance one.
Defaulting to the Smart-Predict-or-Databricks binary — Signal: A predictive need that's genuinely tabular and quick gets over-engineered into a full Databricks ML build, or under-served by Smart Predict's simpler scope. Fix: Name SAP-RPT-1.6 on generative AI hub as a third option for in-context-learning tabular prediction with no training step, before defaulting to either end of the binary.

Decision framework

Decision framework
Decision	Option A	Choose A when	Option B	Choose B when
Predictive engine choice in a SAC-anchored deployment	Smart Predict	Citizen-data-scientist workflow, forecasting/classification/regression inside SAC, governed and repeatable	SAP-RPT-1.6 (generative AI hub) or Databricks	RPT: quick, tabular, no ML team, in-context learning at inference time. Databricks: custom, large-scale, ML-team-owned
Scoping a Joule-in-SAC engagement	Quote fixed price only after confirming SAP Build Work Zone	Joule 2506's conversational-analytics integration requires Work Zone to sync users/roles from SAC — a breaking prerequisite	Quote without checking Work Zone	Not recommended — the gap surfaces after go-live, not during the estimate

How SAP compares

How SAP compares
Capability	SAP	Snowflake	Databricks	Microsoft Fabric
Conversational / NL analytics layer	Joule 'just ask' indexes SAC models plus Datasphere analytic models in a BDC formation, grounded in the same governed semantic layer as human-built stories.	Snowflake Cortex Analyst answers NL questions against a semantic model defined directly in Snowflake, a separate semantic layer from SAC.	Databricks Genie (AI/BI) answers NL questions against Unity Catalog-governed tables and metrics, its own semantic layer.	Power BI Copilot answers NL questions against a Power BI semantic model, generating DAX and visuals from the same dataset business users already query.
Predictive / tabular model options	Smart Predict (in-SAC, citizen-friendly) · SAP-RPT-1.6 on generative AI hub (in-context learning, no training step) · Databricks Mosaic AI (custom ML).	Snowflake Cortex ML functions (forecasting, classification) built into SQL, plus Snowpark ML for custom models.	Databricks' own MLflow-tracked custom models are the native path; no citizen-friendly no-code predictive layer comparable to Smart Predict.	Power BI's built-in AI visuals (key influencers, decomposition tree) cover simple citizen use cases; Azure Machine Learning covers custom ML.

Facts worth quoting

Live connection queries run 100-500 ms p50 with full push-down and support roughly 200 concurrent ad-hoc users per Analytic Model before tail latency degrades.
Import connection caches typically hold about 5 GB per model out of the box (raisable) and serve cached aggregates in under 100 ms p50, at the cost of staleness between refresh cycles (commonly 1-24 hours).
The architectural rule enforced in well-run deployments is to never expose a raw Datasphere SQL view directly to SAC — always wrap it in an Analytic Model first, so currency conversion and restricted measures stay consistent across every story.

Sources

Open in the app →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.