Spotfire Ideas Portal
After working extensively with Mods in production scenarios, one limitation keeps surfacing over and over:
Mods operate on a materialized data view, while native visuals operate on top of Spotfire’s semantic layer.
This difference might seem subtle, but it has major practical consequences.
Native visuals have access to:
Measure definitions (Sum, Avg, etc.)
Aliases (e.g., Sum(A) → sumX)
Synthetic constructs like <Column Names> / <Measure Names>
Implicit wide-to-long transformations
Axis semantics and hierarchy context
Mods, in contrast, only receive:
A flattened DataView
Explicit columns only
No measure metadata
No knowledge of how values were derived
This creates several concrete limitations:
Multi-measure visuals are harder than they should be
In native visuals, multiple measures can be dynamically grouped using <Column Names>.
In Mods, this concept does not exist. Developers must manually pivot/unpivot data just to simulate something the engine already knows.
No access to measure aliases or metadata
If I define Sum(A) as “sumX”, that name is usable in native visuals but completely invisible to Mods.
There is no way to dynamically bind or group measures based on their semantic definition.
Loss of aggregation context
Mods cannot access whether a value is a Sum, Avg, or custom expression.
They also cannot access hierarchy or drill context in a meaningful way.
Axis configuration is purely column-based
No binding to expressions, measure groups, or metadata-driven constructs.
Everything must be pre-shaped into physical columns.
Increased data engineering overhead
To replicate native behavior, users are forced to:
Reshape data (wide → long)
Duplicate logic already defined in visuals
Maintain parallel structures just to support Mods
At this point, Mods are not just “less convenient” — they require a fundamentally different modeling approach.
The core issue is not visualization capability, but lack of access to the semantic layer that already exists in Spotfire.
Suggested improvements:
Expose measure metadata (name, alias, expression)
Provide an equivalent to <Column Names> / <Measure Names> in Mods
Expose aggregation and axis semantics
Optionally allow Mods to consume a pre-aggregation / semantic view instead of only the flattened DataView
Mods are a powerful extension mechanism, but today they operate one layer too late in the pipeline.
Bringing them closer to the semantic model would significantly reduce complexity, eliminate redundant data shaping, and unlock much more advanced use cases.
If Mods are meant to be a first-class visualization layer, they need access to the same constructs that make native visuals powerful.
Hello again, Arnaud.
Dynamic OVER expressions
Example: % of total within a category (e.g., Sum(Sales) / Sum(Sales) OVER (Category)).
In native visuals, this is fully dynamic, filter-aware, and works across hierarchy levels without precomputation.
In Mods, there is no way to define or evaluate such expressions—only to consume precomputed values from the DataView.
Workaround: create calculated columns/measures in Spotfire.
Limitation: removes flexibility, prevents reuse across different groupings, and pushes analytical logic outside the visualization.
Dynamic hierarchy drill with aggregation control
Example: drill-down Region → Country → City with automatic re-aggregation at each level.
In native visuals, hierarchy and aggregation are engine-driven and fully dynamic.
In Mods, hierarchies can be read but not controlled—there is no way to trigger re-aggregation or change grouping logic dynamically.
Workaround: flatten hierarchy levels or use multiple data views.
Limitation: increases data model complexity and prevents true interactive drill behavior.
Hypothetical :Cross-table visualization (revamped cross table scenario)
Question: would the Mods framework enable building a fully dynamic cross-table/pivot-style visualization?
In native cross tables:
Multiple hierarchies (rows/columns)
Dynamic aggregation per cell
Subtotals, grand totals
Expression support per measure
Efficient handling of large datasets
In Mods:
DataView provides a pre-shaped slice of data, not a pivot-capable structure
No control over how data is grouped across multiple axes simultaneously
No ability to compute subtotals/grand totals dynamically at scale
No expression engine to evaluate measures per cell context
Large datasets cannot be reliably pivoted client-side due to performance and windowing
Workarounds:
Pre-pivot or denormalize data in Spotfire
Limit flexibility of rows/columns/measures
Simulate totals manually in JS
Limitations:
Explodes data model complexity
Breaks dynamic exploration (changing dimensions/measures)
Poor scalability and performance
Prevents building a true reusable cross-table visual
In summary, Mods can consume shaped data but cannot dynamically participate in shaping it (expressions, aggregations, hierarchy logic, multi-axis pivoting), which limits parity with native visuals and makes advanced scenarios like a fully dynamic cross-table impractical.
Nothing mentioned here appears to be new compared to ideas already in “future consideration”.
From a practical standpoint, my view is that it would be extremely valuable for near-term Spotfire iterations to prioritize improvements in styling and configuration of core native visuals (such as cross tables, KPIs, bar, line, and pie charts).
Enhancing flexibility in these widely used visuals would likely deliver more immediate impact to end users than continued investment in expanding the Mods framework, especially given the current limitations around analytical capabilities within Mods.
Also, not to overlook the obvious—some of the most upvoted ideas today are still around fundamental gaps like troubleshooting the MS365 SharePoint connector (which, in practice, often just means reliably accessing Excel files). Addressing these high-impact, everyday use cases could arguably bring more value than extending capabilities that are not yet able to match core analytical needs.
Hello Mateus. Thank you for the detailed feedback. This is valuable input.
The points you raise touch on several aspects of the Mods framework. Some areas mentioned may already be supported in the current framework (for example handling multiple measures in wide data scenarios), while other may require further clarification or separate enhancement requests.
For instance, when it comes to the lack of wide data support, I can point you to
allowMultipleMeasuresin the Mods manifest schema.We do build on the same constructs as native visualization. However the Mods API is built around consuming the dataview.
Could you provide one or two concrete examples of:
A specific visualization scenario that is difficult or impossible to implement today with the expected behavior and current workaround needed.
Your submission includes multiple different concerns, it would help to better understand the specific limitations you are encountering in practice. Because of that, this is not something I can treat as a single feature request as written. I encourage splitting the suggested improvements into separate ideas where possible. This helps a lot track, prioritize, and deliver them independently.
I'm marking this idea as Needs Info for now while we gather additional details.