Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Analytics Cloud stories: the delivery guide, not the feature tour

As of 2026-08-14

A story is the consumption canvas of SAP Analytics Cloud — multi-page, interactive, combining charts, tables, KPI tiles, narrative text, filters and input controls. It is also the artefact every business user judges the programme by. Three things are worth knowing before building one: which of the five canonical types you are building, when a story is no longer enough, and how many review rounds to budget.

The five canonical story types

Almost every enterprise story is a variant of five shapes, and naming the shape first settles page count, cadence and audience in one move.

An executive scorecard is a single page of hero KPIs with traffic-light commentary, consumed monthly. An operational dashboard is multi-page and role-tailored, used daily or weekly by sales, supply chain or finance operations. A variance-analysis story sets actual against plan against forecast with narrative explaining each movement, and lives on the close cycle. A predictive story surfaces forecast or classification output inline for a product or risk team. A narrative report is slide-like — text and charts in a reading order — and exists to replace a board pack.

Building without choosing produces the sixth shape: a scorecard that grew detail pages until it became an operational dashboard nobody redesigned. That is the artefact that gets abandoned.

The four design layers, in order

Information architecture comes first: page count — one hero page plus three to five detail pages is the enterprise default — navigation pattern, and an explicit audience per page.

Visual hierarchy comes second: the headline KPI tile carries the answer, supporting charts carry the reasoning, drill tables carry the detail. A reader should learn whether the number is good before reading any chart.

The interaction model comes third: page-level filters, chart-level drilldowns, and story-level input controls where the story feeds a planning model. Input controls are the point at which a reporting story becomes part of a planning process, and they change who owns the artefact.

The performance budget comes fourth and is usually skipped: a render target under two seconds, roughly twelve widgets per page, filter chains no deeper than five, and a connection mode chosen per data source rather than inherited.

Decision table — story, analytic application, or neither

Static drill, filter and linked analysis cover the requirement → a story → fastest to author, easiest to govern, handover-ready for a citizen analyst.

The flow must orchestrate widgets — conditional enablement, programmatic dimension switching, multi-step navigation → an analytic application with scripting → each scripted event becomes developer-owned code nobody else can safely change.

The requirement is a chart SAC does not draw → work down four options in order → configure the standard chart, then compose from standard widgets, then script, and only then build a custom widget.

The visualisation gap is real and recurs across a dozen stories → a custom widget → two to three days for a first build, and every SAC release can break it.

One executive asked once → a screenshot or a standard alternative → a widget for a single dashboard is a maintenance liability with no analytical payoff.

The audience consumes on a phone weekly → a story with an explicit mobile layout → without one, the native client renders a generic phone view people open once.

Where the delivery time goes

The build is not the constraint. Most engagements use five to seven chart types, filter wiring is largely drag-and-drop once the semantic model carries the logic, and the live-versus-import choice is a single decision rather than a per-chart one.

The constraint is iteration: five to ten stakeholder review rounds across four to eight weeks before an enterprise story lands, with each round adding widgets the performance budget then has to reject. Quoting the build and absorbing the reviews is the most common way an SAC delivery slips.

Worth stating to a sponsor early: once Datasphere modelling completes, the large majority of remaining engagement time is story design, development and refinement.

The governance failure that arrives quietly

Story sprawl is what happens when every analyst builds a personal story instead of consuming a governed one, until the same metric is computed five slightly different ways. It looks like self-service enablement for two quarters, then it looks like two dashboards disagreeing about revenue with nobody able to say which is right.

The structural fix is upstream: never point a story at a raw Datasphere SQL view, always wrap it in an Analytic Model first. That is what keeps currency conversion, restricted measures, hierarchy semantics and row-level security consistent across every story built on top.

The second quiet failure is silent staleness on import models. A refresh breaks — a failed job, an expired credential — and nobody notices until a business user says the numbers look wrong. Treat the refresh as monitored infrastructure with an alert, not a schedule set once.

Designing a story an assistant can find

Natural-language answering reads story metadata and the underlying models, which makes titling an adoption decision rather than a cosmetic one. Descriptive story and chart titles, with semantic types populated in the Analytic Model, let a question resolve to the right chart with a citation.

The payoff is specific: it removes the "I do not know which dashboard to open" problem, which is the real reason a well-built story goes unused in a tenant holding hundreds. That costs an hour of naming per story and is worth more than most of the visual work above it.

One caution: it only works on a governed model. An assistant grounded in a tenant full of near-duplicate personal stories answers confidently from whichever it finds, which is story sprawl with a better interface.

Frequently asked

What is the difference between an SAC story and an analytic application?

A story is the drag-and-drop consumption canvas; an analytic application adds a scripting surface — widget properties and events — that orchestrates behaviour a story cannot express, such as conditional widget enablement or multi-step navigation. Prefer the story whenever linked analysis and input controls already cover the requirement.

How many pages should an SAC story have?

One hero page plus three to five detail pages is the enterprise default. The number matters less than naming an audience for each page, because a page without a named reader is the page that accumulates every stakeholder's extra tile during the review rounds.

Why is my SAC story slow?

In order of likelihood: too many widgets on the page, a filter chain deeper than five levels, calculated measures left in the story instead of the model, or a live connection serving a wider audience than live mode scales to. Diagnose by layer — story design, model design, source query — before changing a setting.

How many review rounds should I budget for a story?

Five to ten rounds over four to eight weeks for an enterprise story. That is the schedule risk, not the chart building, and it is worth writing into the plan so the review cycle is a scheduled activity rather than an overrun.

What this page is built on

Read next