Concept card

Custom SAC Visualizations — Four Options Before You Build a Widget

As of 2026-08-29

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

What is Custom SAC Visualizations — Four Options Before You Build a Widget?

Custom visualisation in SAC is four options spanning two orders of magnitude in cost: configure the standard chart, compose in a Story, script it, or build a Web Component widget that every SAC release can break.

"The standard SAC chart doesn't do what we need" is a sentence that leads to a custom widget far more often than it should. Custom visualisation in SAP Analytics Cloud is not one option, it is four, and they differ by roughly two orders of magnitude in cost and maintenance. Working down the list in order is the difference between a two-day change and a permanent maintenance liability.

The four options, cheapest first

1 — The chart you already have, configured properly. A surprising share of "SAC can't do this" requests are answered by conditional formatting, a calculated dimension, a reference line, or a different chart type nobody tried. Cost: hours. Maintenance: none. This is not a joke option; it resolves more requests than the other three combined.

2 — Composition in a Story or Analytic Application. Layering standard widgets, using tabs and containers, driving visibility from a script. Cost: days. Maintenance: low, because everything you used is supported by SAP and survives upgrades.

3 — The SAC Scripting API. Analytic Application scripting gives programmatic control over standard widgets — reacting to events, setting filters, changing what is displayed. Still SAP-supported surface, still upgrade-safe, and it covers most "interactive" requirements that people mistake for visual ones.

Why it matters

Option four is the most interesting to a developer and the most expensive to the client — a combination worth distrusting in your own reasoning, because the maintenance liability never expires.

Key points

Custom visualisation in SAC is FOUR options, not one, spanning roughly two orders of magnitude in cost and maintenance.
Option 1 — configure the standard chart properly. Conditional formatting, calculated dimension, reference line, a chart type nobody tried. Hours, no maintenance.
It resolves more "SAC can't do this" requests than the other three options combined.
Option 2 — compose in a Story or Analytic Application: layered standard widgets, tabs, containers, script-driven visibility. Days, upgrade-safe.
Option 3 — the SAC Scripting API: programmatic control of standard widgets. Covers most "interactive" needs that get mistaken for visual ones.
Option 4 — a Custom Widget: a Web Component SAC loads at runtime. Sankey, non-standard map projections, Highcharts/AmCharts, animation, specialised input forms.
A typical developer ships the first widget in 2-3 days — and EACH SAC RELEASE CAN BREAK IT, permanently.
The widget owns only its render: data, authentication and lifecycle stay SAC-managed through a defined contract.
Build it only when the gap is real AND recurring across many Stories — fifteen dashboards is a widget, one executive request is a screenshot.
Name an owner before building. An unowned widget breaks at the release after its author changes project.

Terms used on this page

Custom Widget: A self-contained JavaScript bundle packaged as a Web Component that SAC loads at runtime into Analytic Applications, exposing properties, events and methods.
Analytic Application: The scriptable SAC application type, as opposed to a Story — where custom widgets and the Scripting API are available.
SAC Scripting API: The programmatic surface for controlling standard widgets — reacting to events, setting filters, changing displays — without leaving SAP-supported ground.
Web Component: The browser-native component standard a custom widget is packaged as, which is why any modern JS framework can produce one.
Widget repository: The tenant-level store a packaged widget is uploaded to, after which every Analytic Application designer can use it.
Data contract: The defined binding through which SAC hands a widget its data. SAC keeps authentication, fetching and lifecycle; the widget renders.
Upgrade liability: The recurring cost that each SAC release may break a custom widget — the part of the estimate that is almost never budgeted.
Composition: Building the required visual from layered standard widgets, tabs and containers instead of new code. Option two, and underused.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →

Guides that answer with this page

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