Designing Interactive Stories: Filters, Input Controls, and Linked Analysis
Learn how to build interactive, business-usable stories using story/page/widget-level filters, input controls, linked analysis, and cross-widget navigation without duplicating widgets or degrading performance.
Explanation
Once a consultant can place widgets on a page, the next skill is making the story behave the way a business user expects: click a region on a map and see the sales chart update; pick a fiscal quarter from a dropdown and have every widget on the page respect it; drill into a product category without leaving the page. This interactivity layer is where most of the real design effort in story-building happens, and it is also where performance and maintainability problems most commonly originate. Filters exist at three scopes: story filters (apply across every page, useful for a fixed context like a fixed fiscal year in a year-end report), page filters (apply to all widgets on that page only), and widget filters (apply to a single chart or table, useful for a 'top 5 customers' widget alongside a full customer list on the same page). Understanding scope precedence matters: a widget filter narrows further than a page filter, which narrows further than a story filter—they combine with AND logic, not override each other. A common intermediate-level mistake is setting a restrictive widget filter and then wondering why a broader story filter 'isn't working'—it is working, but the widget filter is more restrictive and wins. Input controls are dedicated filter widgets (dropdown, list, radio button) that end users manipulate directly, as opposed to filters configured once by the story builder. Input controls can be scoped to affect one page or the whole story, and can be linked to specific widgets rather than all widgets on a page—this selective linking is essential when a page has widgets from different models or different granularities that should not all respond to the same filter. For example, a page showing both a company-wide KPI and a region-specific detail table might use an input control that only affects the detail table, leaving the company KPI stable as context. Linked analysis is the mechanism that enables 'click to filter' behavior: clicking a data point in one widget filters other widgets on the page. This must be explicitly configured per widget (which widgets act as filter sources and which as filter targets); it is not automatic even between widgets on the same model. Overusing linked analysis across many widgets, especially with live data connections, can create cascading refresh chains that are slow and confusing to trace when troubleshooting why a widget looks 'stuck' or shows unexpected data—each linked target refetches data from source on every click. Variables and prompts add another layer, primarily relevant to planning stories and BW live models, where the user is prompted for a value (fiscal year, version, cost center) when opening a story, and that value drives every widget bound to that variable. Unlike filters, which are set after the story opens, variables are resolved at story open/refresh time and often tie into planning version selection—getting this wrong is a frequent cause of planning stories showing 'no data' immediately after open, because the variable's default value doesn't match any existing data. From a performance standpoint, every filter, input control, and linked analysis interaction on a live-connected model triggers a live query back to the source system. On imported models, filtering happens against SAC's in-memory engine and is generally faster but reflects data only as current as the last data import/refresh. Story designers must communicate this trade-off to business stakeholders: 'real-time' live stories will feel slower under heavy filtering than imported snapshot stories, and that is an architectural trade-off, not a bug.
Real project scenario
A supply chain story built on a live S/4HANA connection had six charts on one page, five of which were configured as linked analysis targets for a source bar chart. Business users complained the page took 8-10 seconds to respond after every click. Investigation showed each click triggered five separate live queries back to S/4HANA sequentially. The fix was to reduce linked analysis targets to the two charts that genuinely needed cross-filtering and to convert the remaining widgets to use a shared input control instead, cutting the click-to-refresh time to under 3 seconds and reducing load on the source system.
Common mistakes
• Assuming a story-level filter overrides a more restrictive widget-level filter instead of understanding they combine with AND logic • Configuring linked analysis across too many widgets on live-connected data, causing slow cascading refreshes • Setting default variable/prompt values that don't correspond to actual data, resulting in stories opening with 'no data' • Applying one input control to an entire page when some widgets are at a different granularity and shouldn't be filtered the same way • Forgetting that widget filters persist even when a page filter is later changed, causing confusing 'filter not working' support tickets
Best practices
• Design filter scope deliberately: use story filters for fixed context, page filters for shared page context, widget filters only for intentional exceptions • Limit linked analysis targets to widgets that genuinely need cross-filtering, especially on live connections • Set sensible, tested default values for variables/prompts before handing a planning story to end users • Use selectively-scoped input controls when a page mixes widgets of different granularity or model • Document filter and linked-analysis configuration for each story so support teams can troubleshoot without reverse-engineering the design
Interview angle
Expect scenario-based questions such as 'a user says the story filter isn't working, how do you troubleshoot it' — the expected answer walks through checking widget-level filters, page-level filters, and story-level filters in that precedence order, then checking linked analysis configuration and variable defaults. This tests real troubleshooting instinct, not just terminology recall.