Story Filtering, Linked Analysis, and Cross-Widget Interaction Design
Learn how SAC Stories propagate filters and selections across charts, tables, and input controls using linked analysis, and how to design predictable, performant interaction patterns for consultants building real dashboards.
Explanation
A SAC Story rarely consists of one isolated chart. In real projects, stories combine multiple widgets—tables, charts, input controls, and filters—that must interact consistently so end users can drill, filter, and compare data without confusion. This lesson focuses on the mechanics and design decisions behind that interactivity: story filters, page filters, widget-level filters, input controls, and linked analysis (also called widget linking). Story-level filters apply to every widget on every page unless a widget explicitly opts out or has its own conflicting filter. Page filters apply only within a page and are useful when different pages of the same story analyze different scopes (for example, a Sales Overview page filtered to Actuals versus a Planning page filtered to a specific version). Widget filters are the most granular and override story/page filters for that widget, which is powerful but also a common source of confusion when numbers on the same page do not reconcile—usually because someone applied a hidden widget filter. Input controls are dropdown or list selectors placed on a canvas that let end users change filter values interactively at runtime. Unlike hardcoded filters, input controls are meant for exploration. A key design decision is scope: an input control can apply to the whole story, a single page, or a subset of widgets you explicitly link it to. Getting this scope wrong is one of the most frequent defects in delivered stories—for example, a region selector that silently does not affect a KPI widget because the widget was excluded from the link. Linked analysis governs what happens when a user clicks a data point in one chart—does it filter other charts on the page? By default, charts built from the same model with matching dimensions participate in linked analysis automatically, propagating the clicked member as a filter to other widgets. This is extremely useful for exploratory dashboards but can also produce unexpected behavior when charts are built on different models with only superficially similar dimension names; SAC does not guarantee filter propagation across different data sources unless the dimensions are explicitly compatible. From a runtime perspective, every filter change triggers a new query against the underlying model (live or imported), so heavy interactivity has a direct performance cost. Consultants must think about the query plan implied by their design: how many widgets refresh per interaction, how many dimensions are open at once, and whether calculated measures recompute per click. In live connections (for example, live models pointing to SAP Datasphere views or S/4HANA embedded analytics), each filter change is a live round trip, so poorly scoped filters can generate noticeable latency, especially with large cardinality dimensions. Troubleshooting inconsistent numbers across widgets on the same page almost always starts with checking, in order: widget-level filter overrides, exclusion from an input control's link, different underlying models or versions of the same model, and different variable/prompt values if the model uses input parameters. Story variables (used to parameterize a value across multiple filters or formulas) can also mask the root cause if only partially applied—verify which widgets actually consume the variable versus a separately hardcoded filter. A production-quality story design typically minimizes ad hoc widget-level filters, relies on story or page-level filters plus clearly scoped input controls, documents linking decisions in the story (or in accompanying documentation), and tests interaction with representative business users before go-live to catch scope mismatches early.
Real project scenario
A finance team reports that the 'Total Revenue' KPI card on their SAC story does not change when they use the Region input control, even though every chart on the page updates correctly. Investigation reveals the KPI widget was added after the input control was configured and was never explicitly included in the control's linked widget scope. The consultant re-links the input control to include the KPI widget, retests with a business user, and documents the linking configuration in the story's internal notes tab so future maintainers do not repeat the mistake when adding new widgets.
Common mistakes
• Assuming input controls automatically apply to newly added widgets without checking the link scope • Leaving stray widget-level filters that silently override story/page filters, causing numbers not to reconcile • Expecting linked analysis (click-to-filter) to propagate across widgets built on different, unrelated models • Overloading a single page with too many interactive filters/input controls, degrading performance on live connections • Not testing interaction behavior with actual end users before go-live, missing scope or usability gaps • Confusing story variables with page/widget filters and assuming a variable change updates every widget automatically
Best practices
• Prefer story or page-level filters over many scattered widget-level filters for maintainability • Explicitly verify and document input control linking scope whenever widgets are added or removed • Test cross-widget interactions with realistic user personas before releasing a story to production • Be cautious about linked analysis across different models; validate dimension compatibility first • Limit the number of simultaneously interactive elements on performance-sensitive live-connection pages • Use story variables deliberately and confirm every dependent widget actually consumes them
Interview angle
Interviewers often probe whether a candidate understands the filter hierarchy (story > page > widget) and can explain why two widgets on the same page might show different numbers. Be ready to describe linked analysis limitations across models, how you would troubleshoot filter propagation issues, and how you balance interactivity against live-connection query performance in a design review.