Custom SAC Visualizations — Four Options Before You Build a Widget

"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.

4 — A Custom Widget. A self-contained JavaScript bundle, packaged as a Web Component, that SAC loads at runtime into Analytic Applications. This is where Sankey diagrams, non-standard map projections, third-party charting libraries such as Highcharts or AmCharts, animation-rich displays and specialised input forms actually live. Cost: two to three days for a typical developer to ship the first one. Maintenance: each SAC release can break it, and that liability never expires.

What a Custom Widget actually is

Technically, a JavaScript bundle packaged as a Web Component. It exposes properties (configurable in the Application Designer like any standard widget), events (firable to scripting code) and methods (callable from it). It receives data from SAC through a defined contract — bound to a dataset or model — and renders into its allotted canvas region. Authentication, data fetching and lifecycle are all SAC-managed; the widget owns only its render.

It is developed outside SAC in any modern JavaScript framework — vanilla JS, Lit, React through wrappers — packaged as a manifest JSON plus the bundle, and uploaded to the tenant-level Custom Widget repository, after which every Analytic Application designer can use it.

When it is genuinely worth it

One test: is the visualisation gap real and recurring across many Stories? A Sankey that fifteen dashboards need is a widget. A Sankey that one executive asked for once is a screenshot.

The second test is ownership. A widget is a piece of software your organisation now maintains, in a language the SAP team may not write, with an upgrade cadence set by someone else. If nobody is named as its owner, it will break at the release after the person who wrote it changes projects.

Pitfalls

Reaching for option 4 first. It is the most interesting option to a developer and the most expensive to the client, which is a combination worth being suspicious of in your own reasoning.

Forgetting that each SAC release can break it. Budget regression testing per upgrade, or accept that the widget will fail in production at a time nobody chose.

Building one widget per request. Three near-identical widgets are worse than one configurable widget with three property sets, and the difference is decided at the first one.

Assuming a widget solves a data problem. The widget owns its render only — data, authentication and lifecycle stay SAC's. If the number is wrong, no visualisation layer will fix it.

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.

Common pitfalls

• Reaching for the widget first — Signal: The estimate starts with JavaScript. Fix: Work the four options in order and write down what failed at each step.
• Upgrade risk unbudgeted — Signal: No regression plan tied to the SAC release calendar. Fix: Budget per-release testing, or expect production failure at an unchosen moment.
• One widget per request — Signal: Three near-identical bundles in the repository. Fix: One configurable widget with property sets — the decision is made at the first one.
• Widget used to fix data — Signal: The complaint is that a figure looks wrong. Fix: The widget owns only its render; correct the model or the Analytic Model instead.
• No named owner — Signal: The author is a contractor finishing next month. Fix: Assign ownership before build, or do not build.

Decision framework

Sources

1. SAP Help — SAP Analytics Cloud documentation
2. SAP Help — SAP Datasphere documentation
3. SAP Help — SAP Business Data Cloud documentation
4. Microsoft Fabric documentation — the comparison point for extensibility models
5. DSAG — German-speaking SAP user group
6. ASUG — Americas' SAP Users' Group
7. BARC — independent analyst research